Re: [Diffserv] APIs for diffserv

Brian E Carpenter <brian@hursley.ibm.com> Tue, 15 October 2002 20:57 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15667 for <diffserv-archive@odin.ietf.org>; Tue, 15 Oct 2002 16:57:33 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9FKxIm08401 for diffserv-archive@odin.ietf.org; Tue, 15 Oct 2002 16:59:18 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FKm6v07923; Tue, 15 Oct 2002 16:48:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9FKaXv07007 for <diffserv@optimus.ietf.org>; Tue, 15 Oct 2002 16:36:33 -0400
Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15080 for <diffserv@ietf.org>; Tue, 15 Oct 2002 16:34:15 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9FKaOtt023094; Tue, 15 Oct 2002 22:36:24 +0200
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9FKaNcH059548; Tue, 15 Oct 2002 22:36:24 +0200
Received: from gsine05.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39514 from <brian@hursley.ibm.com>; Tue, 15 Oct 2002 22:36:16 +0200
Message-Id: <3DAC7C39.A17C7C3C@hursley.ibm.com>
Date: Tue, 15 Oct 2002 22:36:09 +0200
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Cc: diffserv@ietf.org, ipng@sunroof.eng.sun.com, Jun-ichiro itojun Hagino <itojun@iijlab.net>
Subject: Re: [Diffserv] APIs for diffserv
References: <200210151342.g9FDgF122300@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Thomas Narten wrote:
> 
> The IPv6 basic and advanced APIs include placeholders/hooks for
> specifying the Flow Label on outgoing IPv6 packets. But the way the
> API is specified, the entire first 32 bits of the IP header can be
> specified, which includes the Traffic Class field. Many of the details
> are unspecified, however.
> 
> Questions:
> 
> 1) What work has been done with regards to specifying an API for
>    setting the Traffic Class fields? Anything other than the IPv6
>    APIs?

There was draft-itojun-ipv6-flowlabel-api-01.txt (April 2001).
itojun may want to comment.
> 
> 2) Is it adequiate for the existing IPv6 APIs (basic and advanced)
>    to simply allow the traffic class to be set via the flow label
>    mechanism (without specifying the details much)?

It needs to be possible to set the 6 bits of the DSCP independently
of either the flow label or the ECN bits. Ditto the flow label. 
If the proposed APIs can't do that, they are inadequate.

> 
> 3) What about APIs for IPv4? Aren't they needed too?

I thought that you could set the TOS byte in the v4 API. Again,
you have to avoid messing up the ECN bits, but I would expect the
TCP/IP stack to take over those bits.

> 
> 4) Or is there an assumption here that endpoint applications setting
>    the traffic class themselves via an API is not particularly
>    interesting or necessary?

It's been debated, but in the general case it is desirable. The DSCP bits
may be set within the stack by a QOS manager, or downstream by a router,
but apps should have the ability in principle. The flow label may be set
within the stack, or in principle by the app.

   Brian

> 
> Have a look at
> 
>     draft-ietf-ipngwg-rfc2553bis-07.txt and
>     draft-ietf-ipngwg-rfc2292bis-07.txt
> 
> for the details of what has been specified so far.
> 
> Thoughts of what (if anything more) should be done with APIs for
> diffserv would be appreciated.
> 
> Thomas
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html