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 that "doesn't carry fine-grain flow labels" > will still get sent through the load balancing mechanics, and packets with > the same flow label will still get forwarded the same way. > > This is probably fine if a few related TCP connections are labelled with > the same flow label, or something like that. > > It would be very bad, though, if the flow label were used, for example, > to tag packets that contain a TCP SYN, or packets that contain IP options,
Agreed. That doesn't meet anyone's definition of a flow, I think. > or all HTTP packets, or packets that want a certain class of services, etc. Why on earth is that bad? It seems perfectly fine to me. That is exactly the kind of scenario I am interested in. > My largest problem with this draft is that I think it is needlessly > complex... What is wrong with specifying a simple default flow label > mechanism, and requiring an API switch to override the values for > each flow? Because we don't agree on what the default should be (apart from label=0). And a per-flow override is not a general solution; the scenarios I have in mind would certainly not be satisfied by that, because they are not microflow based scenarios. 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] --------------------------------------------------------------------
