itojun,
Jun-ichiro itojun Hagino wrote:
>
> >> then why you pushed those non-IANA values in the presentation?
> >> this is the source of confusion.
> >You refer to the last 2 slides of the 14 slide presentation, each WITH
> >BIG TITLES:
> >OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the
> >draft.
> >Your message title confused me: I thought you've read the draft, and
> >based your comments on the draft.
>
> even if they are in the appendix section, it is still true that
> your idea does not work. I would like to suggest you to
> drop the appendix A from the next revision of the draft.
When the WG decides what it wants, we could certainly drop the discussion
of the rejected ideas (but sometimes it is useful to at least list
the rejected ideas, so that we don't have the same discussion again
in 2003).
>
> >at the top of page 27 in the draft, in Appendix A:
> >
> >"...IPv6 headers are 8byte aligned, therefore the length could be
> >represented as the number of 8byte
> > chunks occupied by the headers, in which case the maximum length would
> >be 32Kbytes."
> >
> >With this representation, the receiver would simply shift the value of
> >the field with 3 bits, thus ensuring a 8 byte alignment on accessing the
> >TCP/UDP headers.
>
> fair enough, but I really suggest you to drop the section as well,
> as it won't work.
>
> >> how can you trust IPv6 stack that is in the possession of end user?
> >> they can be hacked up. the only devices you can trust is those you
> >> administer in your diffserv cloud. you can never trust customers
> >> devices.
> >>
> >
> >It seems to me that you are still missing the points made earlier.
> >
> >The Diffserv QoS engines in the access routers do a policing
> >(classification&metering&dropping) that trims the high level QoS traffic
> >-- hacked by a user, or not -- to the level specified in SLAs, TCAs. So,
> >a user, at the most, uses up all that was contracted with the ISP, and
> >paid for, anyway. This is in fact THE BEAUTY of THE MODEL.
>
> you have been saying, in the thread, that the PHB value gets filled
> by the originating end. so which is the truth? if the most
> significant bit of the flow label field is the indication of
> "end-to-end/hop-by-hop", say so in the draft. there's no indication.
The DSCP MAY be rewritten *anywhere* along the path, typically at an administrative
domain boundary. Even if it is initially set by the source host, it MAY be rewritten
each time the packet goes through a multi-field classifier. Thus, the value is not
altered at every hop, but it may not be e2e either.
The distinction made in the proposal by the MSB is between a pseudo-random
value as defined in RFC 2460 Appendix A (for intserv) and a non-random value
(for diffserv). But they are both e2e values, unlike the DSCP. This should
be documented.
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
