Re: Fuzzy-layering... - Towards better QoS solution in the IPv6 network

"Jason Gao" <jag@kinet.com.cn> Wed, 11 September 2002 02:30 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02569 for <ietf-web-archive@odin.ietf.org>; Tue, 10 Sep 2002 22:30:27 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id WAA06733 for ietf-outbound.10@loki.ietf.org; Tue, 10 Sep 2002 22:30:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id WAA06702 for <ietf-mainout@loki.ietf.org>; Tue, 10 Sep 2002 22:27:09 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id WAA02501 for ietf-mainout@loki.ietf.org; Tue, 10 Sep 2002 22:25:28 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from mail.gmmedia.net.cn ([210.51.18.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02497 for <ietf@ietf.org>; Tue, 10 Sep 2002 22:25:23 -0400 (EDT)
Received: from fujitsu [61.149.1.238] by mail.gmmedia.net.cn with ESMTP (SMTPD32-7.04) id A6DB17006C; Wed, 11 Sep 2002 10:13:47 +0800
Message-ID: <028401c2593a$cdfe5e50$5019e29f@fujitsu>
From: Jason Gao <jag@kinet.com.cn>
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: ietf@ietf.org
References: <001f01c254dd$b30bdd40$5019e29f@fujitsu> <3D7B0CAD.C8339952@hursley.ibm.com> <00e601c257e9$19aa68b0$5019e29f@fujitsu> <3D7C924F.E3CE8130@hursley.ibm.com> <017101c25868$6b0d9310$5019e29f@fujitsu> <3D7E085C.BA8FF1EF@hursley.ibm.com>
Subject: Re: Fuzzy-layering... - Towards better QoS solution in the IPv6 network
Date: Wed, 11 Sep 2002 10:27:41 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA02498
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-Loop: ietf@ietf.org
Content-Transfer-Encoding: 8bit

Thanks for the comment, but as both an end user and a programmer I am not satisfied with the diffserv standard (primarily implemented in the IPv4 network) and the IPv6 flow-label draft  proposal to solve the QoS issue in the Internet. As far as I know, it seems that QoS is the Achilles' heel of the IPv4 Internet, though diffserv (or intserv) has been proposed for quite a long time (in the Internet time). (As to the flow label, Mr. Atkinson has made me have to believe that it has no presently clear usefulness yet.)

The IPv6 Internet has the potential to change the impression that the Internet is only able to provide best-of-effort class of service. Presently in the IPv4 internet to assure high QoS one usually throw more bandwidth to the upper layer applications, presuming there will be no network congestion. In corporate network, with support of so-called multi-layer switches, it is a feasible solution. In the large Internet, it seems not.

I mean we cannot just take for granted that the QoS model of the IPv6 Internet should be the same as the IPv4 network. The traffic class bits of the IPv6 header is not necessarily defined identical with the ToS bits of the IP4 header. It is really my private idea, but it is not a private issue.

Jason.

> Jason,
> 
> As co-chair of the diffserv WG, and co-author of the flow label draft,
> I assure you that your interpretation is incorrect in both cases.
> 
>    Brian
> 
> Jason Gao wrote:
> > 
> > > Jason Gao wrote:
> > > >
> > > > > Jason Gao wrote:
> > > > > ...
> > > > > > --- IPv6 flow label assignment
> > > > > >
> > > > > > Transport layer may set a 'control' bit in the IPv6 Traffic Class octet of the initiating packet
> > > > > > during the setup phase of a connection.
> > > > > >
> > > > > >
> > > > > >
> > > > > > The edge router inspects the control bit. If it is set, the edge router can further inspect the
> > > > > > packet, and reserve resource as required by the piggybacked resource reservation header in the
> > > > > > transport layer packet, allocate and/or assign a flow label to the expected connection, put the flow
> > > > > > label in the flow label field of the initiating acknowledgement packet.
> > > > >
> > > > > No. There is no such usage of the traffic class octet. See RFC 2474.
> > > > > Also, only the source host of a packet may set the flow label.
> > > > > See draft-ietf-ipv6-flow-label-03.txt
> > > > >
> > > > >    Brian
> > > > >
> > > > Well, both the draft and RFC 2474 are not the final standard.
> > >
> > > RFC 2474 is a Proposed Standard, which means that fundamental
> > > changes are extremely unlikely. The flow label draft is indeed
> > > still a draft, but there is very strong WG consensus that flow
> > > labels must be immutable.
> > 
> > draft-ietf-ipv6-flow-label-02.txt didn't specify a signaling protocol for the host /end-system and the router / intermediate system to negotiate / assign flow label. The draft said:
> > 
> > 
> > 
> > "
> > 
> > The assignment of a packet to a flow takes various forms, presented
> > 
> >    below:
> > 
> > 
> > 
> >    (1)  The source MAY take part in a signaling protocol that results in
> > 
> >         assigning certain transport connection(s) or application data
> > 
> >         stream(s) to specific flow(s).
> > 
> > 
> > 
> >    (2)  The source MAY be configured to assign certain transport
> > 
> >         connection(s) or application data stream(s) to specific flow(s).
> > 
> > 
> > 
> >    (3)  The source SHOULD assign each new application data stream (e.g.
> > 
> >         RTP streams) to a new flow.
> > 
> > 
> > 
> >    (4)  The source SHOULD assign each new transport connection (e.g.
> > 
> >         TCP, SCTP) to a new flow.
> > 
> > "
> > 
> > 
> > 
> > As:
> > 
> > --- Yet no standard signaling protocol exists to negotiate the flow label.
> > 
> > --- If end nodes behave as (3) and (4) require, each new application data stream or new transport connection should need a new flow, it is very likely that before or along with the negotiation of a new transport connection, end nodes also take part in a process of negotiating new flow label, if a signaling protocol is used.
> > 
> > 
> > 
> > And if we apply fuzzy-layering practices, we may find it is quite convenient to piggy-back the flow-label negotiation signals on the negotiation packets during the setup phase of the transport connection.
> > 
> > 
> > 
> > We can still require that the flow labels must be immutable after the connection is successfully setup.
> > 
> > >
> > > > And both the traffic class octet and the flow label field are subject to further discuss.
> > >
> > > If you are referring to the text in RFC 2460, the traffic class is
> > > definitively specified by RFC 2474. The flow label draft is intended
> > > to be definitive, as soon as it's agreed.
> > >
> > >    Brian
> > >
> > >
> > RFC 2474 not only left two pools of codepoint space for experimental / local use but also left the code point number in the pool of 'standards action' unassigned. So I don't think it is definitive. I mean it did not prohibit the use of one bit in the traffic class octet for control purpose.
> > 
> > Jason.
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> On assignment at the IBM Zurich Laboratory, Switzerland
>