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