I'm taking no position here on whether labeling like presented below should or should
not be done, but...
Margaret Wasserman wrote:
> - All HTTP packets get the same flow label.
>
> How would this work with a load spreader that is
> trying to s
> Cc: 'Brian E Carpenter'; Rajahalme Jarno (NRC/Helsinki);
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Flow label draft issues & new text
>
>
> Michael Thomas wrote:
> > ... snip
> > > What doesn&
Margaret Wasserman wrote:
> This seems a lot simpler than the current doc, and would allow
> routers to make some immediate use of the flow label field to
> limit situations where they need to parse into the packet to
> find upper-layer ports (parse once, and cache the value based
> on src/dst/flo
Tony's comments on the text seem valid to me.
Brian
Tony Hain wrote:
...
> I do have comments on the text. I would like to see the following
> changed from:
> 4. Flow Labeling Requirements
> (4) The source SHOULD assign each new transport connection (e.g.
> TCP, SCTP) to a new flow
Margaret Wasserman wrote:
>
> I think that the problem is that we have different ideas about
> what the purpose of this document is.
>
> I, personally, would like to see a document that defines how hosts
> should set the flow label, in the absence of knowledge to the
> contrary.
That is not t
Margaret Wasserman wrote:
> I think that the problem is that we have different ideas
> about what the purpose of this document is.
>
> I, personally, would like to see a document that defines how
> hosts should set the flow label, in the absence of knowledge
> to the contrary. Something like:
I think that the problem is that we have different ideas about
what the purpose of this document is.
I, personally, would like to see a document that defines how hosts
should set the flow label, in the absence of knowledge to the
contrary. Something like:
- Start with a random number
Margaret Wasserman wrote:
>
> >If
> >you want to talk DiffServ, IntServ, or something of that flavor, the
> >flow label would be signaled, the router would recognize it during
> >packet classification and deal with it how it sees fit.
>
> So, all of the routers would have to participate in sig
>If
>you want to talk DiffServ, IntServ, or something of that flavor, the
>flow label would be signaled, the router would recognize it during
>packet classification and deal with it how it sees fit.
So, all of the routers would have to participate in signalling to
know whether the flow label was
Michael Thomas wrote:
>
> Margaret Wasserman writes:
> >
> > If the WG really wants to define the flow label so that it can be used
> > for signalling-based mechanisms like RSVP, NSIS and diffserv, with the
> > clear understanding that this makes the value _USELESS_ for the types
> > of ap
Michael Thomas wrote:
> ... snip
> > What doesn't work is if there may be non-zero values in
> the flow label > that actually don't label flows. How is a
> load-balancing or load-spreading > router supposed to know
> that this isn't a flow label?
>
>Er, well, it _doesn't_. I guess I ju
Margaret Wasserman writes:
>
> >
> >Maybe I'm in left field here, but I thought that a
> >transmitter who didn't mark packets' flow label
> >was supposed to set it to zero. In that case, the
> >router could conceivably resort to classifying packets
> >the old fashioned way -- eg transport
>
>Maybe I'm in left field here, but I thought that a
>transmitter who didn't mark packets' flow label
>was supposed to set it to zero. In that case, the
>router could conceivably resort to classifying packets
>the old fashioned way -- eg transport headers.
The problem is that the current specif
Margaret Wasserman writes:
>
> >
> >Jarno answered this one I think, but my point is that *they don't need to
> >know*. They just behave the same way in all cases, and the traffic that
> >doesn't carry fine-grain flow labels will just not get load balanced.
>
> The problem is that the tra
Margaret Wasserman wrote:
>
> >
> >Jarno answered this one I think, but my point is that *they don't need to
> >know*. They just behave the same way in all cases, and the traffic that
> >doesn't carry fine-grain flow labels will just not get load balanced.
>
> The problem is that the traffic tha
Keith Knightson wrote:
>
> All,
>
> What happened to the proposal to partition the label space to clearly
> and formally delineate the different possible uses?
>
> Surely this would elminate any possible ambiguous and/or conflicting use.
There was no consensus to go that way. So we looked for
All,
What happened to the proposal to partition the label space to clearly
and formally delineate the different possible uses?
Surely this would elminate any possible ambiguous and/or conflicting use.
Regards
Keith Knightson
>
>Jarno answered this one I think, but my point is that *they don't need to
>know*. They just behave the same way in all cases, and the traffic that
>doesn't carry fine-grain flow labels will just not get load balanced.
The problem is that the traffic that "doesn't carry fine-grain flow labels"
Margaret Wasserman wrote:
>
> Hi Brian,
>
> >[BC] Probably, but near the source or destination this is not necessarily
> >true. In a non-diffserv, non-intserv scenario, using the triplet
> >{source, dest, flow label} to split the traffic could be interesting.
>
> And, how do load balancing rout
Margaret Wasserman wrote:
> >[BC] Probably, but near the source or destination this is
> not necessarily
> >true. In a non-diffserv, non-intserv scenario, using the triplet
> >{source, dest, flow label} to split the traffic could be interesting.
>
> And, how do load balancing routers determine t
Hi Brian,
>[BC] Probably, but near the source or destination this is not necessarily
>true. In a non-diffserv, non-intserv scenario, using the triplet
>{source, dest, flow label} to split the traffic could be interesting.
And, how do load balancing routers determine that this is a non-diffserv,
[EMAIL PROTECTED] wrote:
>
> Margaret,
>
> The flow label specification should define the default usage of the flow label, and
>allow for future specification of more specific usages. IPv6 WG needs to reach
>consensus on the default usage, document that in the flow label specification, and
>n
[EMAIL PROTECTED] wrote:
>
> Hi Jarno,
>
> [EMAIL PROTECTED] wrote on 11 Sep 2002:
> > IP has never promised to not reorder packets. I do not
> > think we need to build in any guarantees now either.
>
> It is not a matter of having IP guaranteeing packet
> sequence, but rather to keep packet re
Hi Brian,
> To summarise: a source that chooses to use coarser flow labels deprives
> itself of downstream load balancing, but gains in downstream service
> differentiation. The draft is intended to allow that tradeoff rather
> than force one choice or the other.
I fully agree with you on this.
Margaret,
This is old ground and I thought we had got past this two metings ago.
Margaret Wasserman wrote:
>
> Hi Brian,
>
> >The draft is intended to allow several *simultaneous* usage scenarios to
> >coexist. Yours is one of them. Diffserv is another. RSVP, and potentially
> >NSIS and the re
Hi Jarno,
[EMAIL PROTECTED] wrote on 11 Sep 2002:
> IP has never promised to not reorder packets. I do not
> think we need to build in any guarantees now either.
It is not a matter of having IP guaranteeing packet
sequence, but rather to keep packet reordering limited
to avoid bothering TCP too
Margaret,
The flow label specification should define the default usage of the flow label, and
allow for future specification of more specific usages. IPv6 WG needs to reach
consensus on the default usage, document that in the flow label specification, and not
set any unnecessary or ideological
Hi Brian,
>The draft is intended to allow several *simultaneous* usage scenarios to
>coexist. Yours is one of them. Diffserv is another. RSVP, and potentially
>NSIS and the recent RSVP2 proposals are others.
I don't believe the draft achieves this goal, and I don't personally
believe that we s
below...
Erik Nordmark wrote:
>
> > Well yes, although I've not been sure from the start of this discussion
> > why that is any business of *this* working group. Worrying about that
> > really belongs to whatever WG standardizes a specific use of the label.
> > All we need to do, imho, is establ
> Well yes, although I've not been sure from the start of this discussion
> why that is any business of *this* working group. Worrying about that
> really belongs to whatever WG standardizes a specific use of the label.
> All we need to do, imho, is establish the appropriate boundary
> conditions,
Robert Elz wrote:
>
> Date:Wed, 21 Aug 2002 14:05:30 -0400
> From:Thomas Narten <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> [quoting Brian]
> | > It's a matter of interpretation (you could ask the same question
> | > about some ways of using the flo
Date:Wed, 21 Aug 2002 14:05:30 -0400
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
[quoting Brian]
| > It's a matter of interpretation (you could ask the same question
| > about some ways of using the flow label for diffserv
| > classifi
Thomas Narten wrote:
>
> > It's a matter of interpretation (you could ask the same question
> > about some ways of using the flow label for diffserv
> > classification).
>
> It would be far better if different readers didn't have to think too
> hard about this. General comment. IMO, what is need
> It's a matter of interpretation (you could ask the same question
> about some ways of using the flow label for diffserv
> classification).
It would be far better if different readers didn't have to think too
hard about this. General comment. IMO, what is needed is a very short
and simple specif
It's a matter of interpretation (you could ask the same question
about some ways of using the flow label for diffserv classification).
In my interpretation, a server load balancing mechanism that recognizes
and caches new labels is a flow state establishment method.
Brian
Thomas Narten wrote
> "The method by which the flow state is cleared from the IPv6 nodes
> is to be defined by the flow state establishment method used to set
> up the state. This implies that IPv6 nodes unable to classify a
> packet to an existing flow SHOULD NOT establish any flow-specific
> state unless so instruc
Date:Tue, 13 Aug 2002 20:25:17 +0300
From:[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| How about this (changes in the second sentence):
Looks OK to me. But I understood what it meant the first time, so
I'm perhaps not the best judge... Do those who thoug
[EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Flow label draft issues & new text
>
>
> Date:Mon, 5 Aug 2002 09:53:49 +0300
> From:[EMAIL PROTECTED]
> Message-ID:
> <[EMAIL PROTECTED]>
>
> | any suggestions on how to make the tex
Date:Fri, 02 Aug 2002 10:40:18 +0200
From:Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think in the end this is an argument about nothing.
I think I agree with that.
| > This implies that IPv6 nodes SHOULD NOT establish any flow-spe
D]; [EMAIL PROTECTED]; Hinden Bob
> (IPRG)
> Subject: Re: Flow label draft issues & new text
>
>
> >I don't agree with the "SHOULD NOT" above...
> >
> >There are some potential uses for flow identification that
> do not rely on
> >any sort o
PROTECTED];
> [EMAIL PROTECTED]; Hinden Bob (IPRG)
> Subject: Re: Flow label draft issues & new text
>
>
>
> Hi Jarno,
>
> >The method by which the flow state is cleared from the IPv6
> nodes is to be defined by the flow state establishment method
> used to
I think in the end this is an argument about nothing.
> This implies that IPv6 nodes SHOULD NOT establish any
> flow-specific state unless so instructed by a specific flow state establishment
>method.
>
What Margaret and itojun refer to are flow state establishment methods that
happen to co
>I don't agree with the "SHOULD NOT" above...
>
>There are some potential uses for flow identification that do not rely on
>any sort of flow establishment mechanism or signalling, such as the use of
>flow labels for load balancing.
>
>To have a useful flow label for these mechanisms, an IPv6 node
Hi Jarno,
>The method by which the flow state is cleared from the IPv6 nodes is to be defined by
>the flow state establishment method used to set up the state. This implies that IPv6
>nodes SHOULD NOT establish any flow-specific state unless so instructed by a specific
>flow state establishme
I have gone through all the flow label related issues raised on the list during the
last month. In my opinion there were no big issues, but some clarifications in the
text were necessary. I have included a new revision of the text, with the summary of
the changes below.
I'd like you to raise a
45 matches
Mail list logo
