Unless I've missed something, I've not received any responses to the
attached message. I interpreted the silence as a sign that there is
no need to update 2292bis wrt the issues in this thread. Otherwise,
please let me know.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Wed, 06 Nov 2002 13:44:49 -0500,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
> With regards to the basic API:
> - Will we want the basic API to ever allow a way to specify the
> Traffic Class? If so, will it be better to define a new extension or
> to overload the Flow Label?
> - Should we point out that some previous versions of the basic API
> copied both traffic class and flow label info into packets and that
> this is now beleived to be wrong and should be fixed?
> I'm OK with either saying setting the Traffic Class through the basic
> API won't be done in the future, or saying it can be added but in a
> way that is completely backwards compatable and will work smoothly
> with 2292bis (assuming we need two ways of setting the bits).
I personally prefer to deprecate the access to Traffic Class by the
sin6_flowinfo field (i.e. by the basic API), because
- it (of course) makes the (future) API simple.
- as far as I know, there should be very few (or even no) applications
that rely on the feature. so the backward compatibility issue
should be not so serious.
I know opinions on the compatibility often varies, and I'm open to
others' opinions.
> Then there is the Advanced API. Again, from Bill:
> Bill Fenner <[EMAIL PROTECTED]> writes:
>> I am still concerned about the interaction between 2292bis's IPV6_TCLASS
>> and these implementations, but perhaps we should let 2553bis go with the
>> "not currently specified" wording and make the interaction clear in
>> 2292bis? (Has the WG as a whole had a chance to see the suggesiton of
>> leaving sin6_flowinfo simply unspecified?)
> 2292 doesn't address the flow label. But it does have a way of setting
> the Traffic Class. But it doesn't mention how it interacts with
> Traffic Class settings via the (old) basic APIs. If the intention is
> that the old ways are invalid, and that one only sets traffic class
> through the advanced API, I think the current approach is fine. Is
> that what folks are thinking here?
Excuse me, what do you mean by "the current approach"? Do you mean
that "2292bis has a way of setting the traffic class but it doesn't
mention the interaction with the (old) basic API"?
If so, and assuming we agree on deprecating this part of the basic
API, I agree.
However, if our consensus is that some backward compatibility should
be provided, I guess 2292bis needs to talk about the interaction.
> Finally, 2292bis seems to assume the Traffic Class is 8 bits in
> size. It's not any more. It's 6 bits, with the ECN bits explicitly a
> separate field. So perhaps 2292bis should be updated to reflect the
> new size and have separate way of setting the ECN bits? Or at least,
> the text should make it clear how one sets one and not the other, etc.
(this was discussed before at least partly, but)
I believe 2292bis clearly separates the notion of (6-bit) traffic
class and 2-bit ECN. For example, section 6.5 contains the following
sentences:
Returning the received traffic class is useful for
programs such as a diffserv debugging tool and for user level ECN
(explicit congestion notification) implementation.
An example is an implementation of ECN in the kernel,
setting 2 bits of the traffic class value.
The confusing part would be wording such as "traffic class" (assuming
8 bits) or the socket option name IPV6_TCLASS. In this sense, the
comment for the ip6_un1_flow field of the ip6_hdr structure would also
be confusing:
uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */
As I responded before, I personally think the current wording is
okay. However, if there's a strong demand to clarify this much more,
I'd propose to add a note like this:
[RFC-3260] separates an 8-bit field of the IPv6 header, which was
originally called a single "traffic class" field, into a 6-bit DS
field and a 2-bit ECN field. However, since this API only provides a
single way to get access to the whole 8 bits, the previous terminology
"traffic class" will be used to specify the whole bits within this
document.
Does this make sense?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--- End Message ---
