Re: [magma] BoF: New draft and ML for well managed IP multicasting issues
Pekka Savola <pekkas@netcore.fi> Fri, 24 September 2004 06:58 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14038; Fri, 24 Sep 2004 02:58:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAk9S-0003Mj-Qt; Fri, 24 Sep 2004 03:05:55 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAk1b-0001Gj-DH; Fri, 24 Sep 2004 02:57:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAjyZ-0000uz-R3 for magma@megatron.ietf.org; Fri, 24 Sep 2004 02:54:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13913 for <magma@ietf.org>; Fri, 24 Sep 2004 02:54:38 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAk5S-0003JC-Ln for magma@ietf.org; Fri, 24 Sep 2004 03:01:50 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8O6rpG02130; Fri, 24 Sep 2004 09:53:51 +0300
Date: Fri, 24 Sep 2004 09:53:50 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Hiroshi Ohta <ohta.hiroshi@lab.ntt.co.jp>
Subject: Re: [magma] BoF: New draft and ML for well managed IP multicasting issues
In-Reply-To: <6.1.0.6.2.20040916181141.03501af8@imf.m.ecl.ntt.co.jp>
Message-ID: <Pine.LNX.4.44.0409240859350.510-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Cc: magma@ietf.org, mac-external@lyris.nortelnetworks.com
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd
On Thu, 16 Sep 2004, Hiroshi Ohta wrote: > The draft is: <draft-hayashi-maccnt-00.txt> > The mailing list is: <mac-external@lyris.nortelnetworks.com> Are there web-accessible archives for that list? That's pretty much a requirement.. A few comments on the draft itself, which seems to be needing a lot of work yet to be more precise about the actual requirements. Two higher-level comments: 1) you state that ASM must be supported, but you don't specify requirements for restricting the users from disturbing the integrity of the group by sending bogus packets to it (see draft-ietf-mboned-mroutesec-03). Does this need to be added or at least referred to? 2) the technical solution seems to be pretty close to what MSEC WG (http://www.ietf.org/html.charters/msec-charter.html and RFC3740) has been standardizing. This may not directly address NSP's accounting requirements, but those could be gathered from the first-hop routers with appropriate (or extended) MIBs. substantial ----------- This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. ==> this uses the old boilerplates, but what's worse is that the right to produce derivative works is not granted -- that's unacceptable. By the process, such documents cannot be considered as WG items (for example), and I'd argue this would be an unacceptable basis for this BoF. Please change the boilerplate. ==> also, the standard IPR disclosures and other boilerplates at the end of the draft are missing. These are needed. .... However, multicasting according to current standard has drawbacks compared to unicasting. Appropriate accounting of each user is not possible when multicasting is used while it is possible under unicasting. Accounting consists of grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. ==> I don't think this is entirely accurate. You can get accounting statistics if you just bother. It's more of an issue with deployment assumptions and the granularity of the information. For example, one could monitor the amount of multicast traffic per group or per IGMP/MLD joiner at the first hop router. If all your users would have their own virtual interface, you'd get per-user statistics. ==> "current standard" -- reword? (these are not full standards, and there is no single standard) On the other hand, in multicast communication as in Fig.1, the server just feeds its information to the multicast router. Then, multicast router replicates the information to distribute the clients. According to the current standard (e.g., IGMPv3[1] or MLDv2[2]), the multicast router feeds the replicated information to any link which has at least one client requesting the information. In this process, no eligibility check is conducted. Any client can request to receive the information. In other words, no accounting capabilities are provided for multicasting by the current standard. ==> the word "accounting" seems incorrect here. What you meant was probably "authorization" ? The same later on. You need to be careful which terms you use. The best might be if you said precisely what exactly you believe the operator or the content provider needs to be able to do if it's not authorization. Similar later on, but there are also instanced where "accounting" is valid. .... (1) Network should be able to identify each client when eligible user access, and should be able to reject to connect ineligible clients. ==> the first part is confusing, reword to e.g.: (1) Network should be able to identify eligible user accessing the service, and should be able to reject to service ineligible clients. Note: this requirement should actually be broken in two (if that was what you meant), roughly: 1.a) the service must be able to accept eligible users, and deny ineligible users. 1.b) the service must be able to identify every user using the service. (does the service need to be able to identify the eligible users before they use the service ["all the potential users"], or just after they've used it?) .... (2) Network can grasp each client's behavior. For example, network should be able to detect: - that the client connects to the network, - that the client starts receiving certain information, - that the information which the client is receiving, - that the client terminates receiving the information, - that the client disconnects from the network. ==> you need to be much more precise here. First, you need to specify clearly what you mean by "client", "connect", etc. Why would this particular specification require to know when the user turns on his computer? That's well beyond the scope of multicast accounting! You also need to be much more precise which client behaviours you want to be able to track. Please state the full list of actions. ... (3) Mobility functions should be supported as an option so that users can use the service from anywhere. ==> 'Mobility' can mean a dozen different things. Please be more precise here what you mean. I suspect you mean that the user must be able to be authorized to get particular multicast feed no matter where he is in a particular providers network. (e.g., the accounting cannot be done based on IP addresses, unless IP addresses are static, or something like Mobile IP is used). What about inter-provider issues -- if the user moves temporarily to another ISP, which may or may not support this at all? ... 4. Application example and its specific requirements ==> the text here is more a description of a scenario than the actual, solution-independent requirements. Therefore I'd consider rewording this to just say "scenario description", and remove the "requirement" word completely. .... The NSPs are responsible for delivering the content and are required to meet certain QoS level or SLA (service level agreements). For example, video quality is very sensitive to packet losses. So if a NSP cannot meet the quality requirements due to limited network resources if it receives an additional user request, the NSP should reject that end user clientCYs access request instead of charging the user for bad services. ==> where is the problem here? last hop congestion? (the multicast distribution tree is already there...) 4.1.2.3 Authentication Requirements There are two different aims of authentication. One is an authentication to network access, and another one is to each content. For the first case of authentication, NSP has a AAA server, and for the second case, each CO has a AAA server. In some cases, COs delegate (outsource) the operation of user authentication to NSPs. ==> this is not clear. Why should the NSP have an authentication on who can use the multicast? Do you assume that NSPs would charge extra for multicast-enabled network connectivity? This seems like a broken model to me... An important issue that discourages the wide deployment of IP multicast services is lack of multicast network management functions, especially an effective multicast accounting function. In IP multicast-based Internet TV, we should support a network model where many content owners provide their content to several NSPs which are different entities, and where each provider individually holds their customer information. ==> there is no technical requirement for the NSPs to have any customer information as far as I can see. On one hand, NSPs of commercial multicast services need to accurately identify the users and collect their usage information to generate correct billing information. ==> why should the NSP bill for the multicast feeds? It's just bits. If they want to share the profits, why not strike deals directly with the content owners for redistribution expenses? Seems much better model to me. This is clearly written from NSP revenue perspective. It seems clear to me that content owners wish to get some money from each recipient, but the manner in which the NSP gets profits from that seems irrelevant. The best way would probably be to do this out of the tecnical context, with an agreement with the content provider or a flat rate with the user ("2$/month for the ability for multicast services", plus the fees directly to the content owner") editorial --------- ==> there are 3 too long lines (72 chars is the max) in the draft, and 5 non-ascii characters. The intention of this I-D is to initiate the discussion on especially accounting issues related to well-managed IP multicasting services and to invite people to participate a potential IETF BoF/WG to discuss these issues and find solutions for them. ==> this text and the document title is misleading. They seem to imply that multicast services which would not have these accounting etc. requirements placed forward in this memo would not be "well-managed". The same later on, e.g., in section 3. ... To match the accounting information with a particular end user client, the end user client has to be authenticated. Usually the account information of an end user client for content access is maintained by the COs. An end user client may have different user accounts for different COs. The account is usually in the format of (username, password) so an end user client can access the content services from anywhere. For example, an end user client can access the CO from different NSPs. It should be noted that the user account used for content access can be different from the one used for network access maintained by NSPs. ==> this seems to be about authentication or authorization, not about accounting (under which section it is now) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma
- [magma] BoF: New draft and ML for well managed IP… Hiroshi Ohta
- Re: [magma] BoF: New draft and ML for well manage… Liu Enhui
- Re: [magma] BoF: New draft and ML for well manage… Pekka Savola
- Re: [magma] BoF: New draft and ML for well manage… Pekka Savola
- Re: [magma] BoF: New draft and ML for well manage… Haixiang He