Date:        Thu, 06 Sep 2001 21:36:03 -0400
    From:        Alex Conta <[EMAIL PROTECTED]>
    Message-ID:  <[EMAIL PROTECTED]>


  | > | Our proposal needs more work, we knew that -- to have both Intserv,
  | > | and Diffserv work with the same label, Brian and I acknowledged that.

  | The above "the same label" was meant "the same label space".

Then that's not good enough - they need to be able both work on the
exact same label.

  | As a further clarification, it means to work on removing a static
  | separation of the flow label space.

Since Christian has just proposed a compromise, which would embed that
static separation, that's nice to hear...   A unified space is all that
I think is reasonable.

  | Your statements suggest that any specification of the use of the flow
  | label with Diffserv must work with the use of the flow label by Intserv,
  | and any other possible  schemes to be invented...

Intserv is irrelevant to me ... I'd characterise my statements as more
along the lines of expecting that any proposed used of the flow label
be able to use it as it is defined.  If one user can adapt to the
definition that exists, and another cannot, well, then one is going to
have a seeming advantage over the other.   Live with it.

  | In principle, and I said this before with other words, I do not have
  | trouble with a standard in which both Intserv and Diffserv can share the
  | same label space, and therefore the same label.

It is no good to just share the label space, to be effective, they both
need to be able to use the same precise label (as one packet can only
carry one label, and it can pass through both diffserv and intserv
sections of the net - and perhaps others yet to be invented).

  | But I should say that I am troubled, if the standard is not applied
  | fairly, and equally on both sides.

Wah - mummy - its not fair, he has pink icecream, I want pink icecream too!!!
You're allergic to strawberries, they make you itch, and you don't like it.
I don't care, it's not fair, I want pink icecream too!!!

A fine argument from a 4 year old...

  | Your statements above, and implicitly anything supporting them, I am
  | afraid, create a double standard, don't you think?

No.

  | One, in which it is OK that the specification of the use of the flow
  | label with Intserv, in Appendix A of RFC 2460, which, by requesting
  | the use of a Pseudo-Random Number, excludes currently the use of the
  | flow label by Diffserv, which back in 94-95, 97-98, was  "a possible
  | scheme that could be invented in the future".

The flow label identifies flows,  it should be doing no more than that.
A PRNG is just fine for that.   Anyone is free to make use of that
identification for any purpose they can dream up.  Changing it however
is an entirely different thing.   No double standards at all.

  | According to the proposal, there is a separation of label space. That
  | ensures that the use of the flow label with Intserv, and Diffserv do not
  | intersect,

For me, that isn't good enough.   These aren't different choices, in which
you pick whichever one you like, and use the label that suits.   Rather,
you have to use the one that is used to actually classify the packets,
except there isn't just one - there can be many, so they all need to
work together.

  | > As I understand intserv (which isn't a lot, nor diffserv), a static
  | > value isn't very useful.
  | 
  | Why not?

I explained that off list.

  | > As I understand it, and do correct me if I'm wrong - that's not really
  | > needed. 
  | I correct you.

Again, off list, in an earlier reply, I explained why...

  | But please do not misunderstand me, 
  | if it is a good approach, please write it up.

Unfortunately, at the minute, I don't have time, I have other things
to do that are more urgent.   Further, it isn't for me to define how
diffserv (or intserv, or anyone else) should do their thing - I just
threw out a suggestion that I think would work just fine.   Again, off
list, I have tried to explain to you just how.

  | I thought that as a Hop-by-Hop header option, only for Diffserv, it is
  | not going to provide the same efficiency as the flow label,

Close enough, it is.

  | a fixed size field at a fixed offset in the main header,

That one it also is, absolutely.

  | and the advantage of using the classification engine

That one might take a little extra work, if it is appropriate at all.
I'm not the one to answer - the problem would be more or less that the
bits would come from two different places in the packet, one if you're
doing diffserv, a different one for intserv.   Whether that's a really
difficult problem to handle (in silicon, it is trivial in software) I'll
leave for someone else to answer.

  | for both Intserv and Diffserv. I replied to you in more detail, with my
  | observations, in a private message.

Yes, I replied...

  | Even though we knew it does not really matter whether the flow label
  | value is PRN or not, it is exactly why Brian and I put out a proposal
  | that would not change the PRN rule for the Intserv use of flow label --
  | the proposal of a static separation of the flow label space.

I'm not sure if I'm not being clear, or if you're just ignoring the
requests - Brian clearly understands what I am asking, and why.

Static separation isn't the answer to anything - that is the problem
that I am trying to avoid - the precise problem, almost the only problem.

kre

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to