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 the intended purpose of the current draft, which is
to set boundary conditions that allow hosts, routers, and network
processors to stop treating the label as an MBZ field. Once we
have set these boundary conditions, we can then work out specific
scenarios. It is not a given that the default scenario is load
balancing; I doubt if there is a default scenario, apart from label=0.
Michael Thomas, Tony Hain and Brian Haberman have responded to your
other comments much as I would. But basically, a flow is whatever
the source host decides is a flow.
Brian
> ...Something like:
>
> - Start with a random number
> - Label each microflow (i.e. one half of a TCP, UDP or
> SCTP communication) with a new flow number
> - Supply an API for flow label override on a per-microflow
> basis
>
> Based on that document, it would be safe for routers to assume
> that a non-zero flow-label labels a microflow.
>
> If other WGs want to define signalling mechanisms that run
> above IP, those mechanisms can use the aforementioned API to set
> the appropriate signalled values. But, anything that wants to do
> this would have to be consistent with the fact that some routers
> will assume that the src/dest/flow label triplet labels a microflow.
>
> 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/flow label).
>
> Granted, this might make it harder to use the flow label field for
> mechanisms that want to do things other than label microflows, but
> it we already have a traffic class field for things that want to
> label packets with traffic classes.
>
> Margaret
>
> At 05:05 PM 9/12/02, Brian Haberman wrote:
>
> >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 signalling to
> > > know whether the flow label was used for DiffServ, IntServ, etc.?
> > >
> > > Or, it would just work to use the flow label for load balancing,
> > > even it it contained a DiffServ or IntServ value, instead of
> > > labeling a microflow?
> >
> >How DiffServ and IntServ work with the flow label is yet to be
> >determined. All I am saying is that the current spec does not
> >preclude any of the functions mentioned above. Isn't that the
> >point of the draft?
> >
> >As Matt said, the host knows best what a flow is. Whether that
> >flow gets signaled to routers for special handling or not is
> >outside the scope of this doc.
> >
> >Brian
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
