Re: [16NG] Re: traffic classification

Jari Arkko <jari.arkko@piuha.net> Sun, 04 February 2007 19:42 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnFi-0005f6-4E; Sun, 04 Feb 2007 14:42:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnFg-0005f0-Tj for 16ng@ietf.org; Sun, 04 Feb 2007 14:42:16 -0500
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDnFe-0000AQ-Gh for 16ng@ietf.org; Sun, 04 Feb 2007 14:42:16 -0500
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0C429198776; Sun, 4 Feb 2007 21:42:07 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 56ACE1986AF; Sun, 4 Feb 2007 21:42:04 +0200 (EET)
Message-ID: <45C6370C.9090603@piuha.net>
Date: Sun, 04 Feb 2007 14:42:04 -0500
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@motorola.com>
Subject: Re: [16NG] Re: traffic classification
References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com>
In-Reply-To: <45C48A0A.1010301@motorola.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

There are a couple of issues. The main technical question
is whether host and base station need to be synchronized
with respect to the CID etc that they use. For instance, if
the host puts something in CID = X and the base station
drops it because it felt that it should have travelled in
CID = Y. If they need to be synchronized, then we can
talk about whether that's something that should be
left to policy or mandated in the standards. I think it
is pretty obvious that we're not mandating what
port numbers or address ranges should be treated
in what way; that's a standard policy/qos filtering
function. If you agree, then its not clear to me why
DSCP is any different.

The non-technical issue is whether the topic belongs
to the IEEE or IETF standard. My thinking is that
it should be an IETF function if and only if IP needs
to do something for which there is no corresponding
link layer functionality. For instance, we map multicast
IP addresses to multicast L2 addresses because there
is no L2 multicast address resolution function. In
our 16ng case there appears to be a link layer function
for mapping IP packets to CIDs. I don't know if that
function is perfect or not, but it does seem to be
an IEEE issue.

Jari


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng