Brian,

Brian E Carpenter wrote:
> [...]
> e) the only way I can see to do this is to compress port # and protocol #
>    information into the flow label.
> [...]
> 
>   Brian

Brian,

This would allow any router on the path of a packet to apply the same
5-tuple 
classification rules, which is a nice feature.

But, I am not sure why you exclude other ways, like associating a
particular 
value to the 5-tuple, ala MPLS, and have all downstream routers "know"
and 
classify based on that "known" value.

As classification is done for practical purposes to place packets in
distinct processing queues, I have mixed thoughts about the practicality
of
having both source and destination port numbers, and as a matter of fact
the 
5-tuple for that purpose. I wonder in fact, if one would have a straight
answer
on how many router implementations, including IPv4 ones, do per flow
(5-tuple) 
queuing today, or plan to have that in the future.

Alex

> 
> Christian Huitema wrote:
> >
> > Brian,
> >
> > I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv."
> > I think you have a model there in which the diffserv bits are set by some
> > intermediate router, after examining the "5 tuple" of the packet. In this
> > context, the five-tuple works somewhat. But it does not work well with IPSEC
> > (ports are hidden), it does not work well with floating port applications
> > such as VoIP, and it leads to some interesting header manipulation when we
> > encounter stacks of IPv6 headers.
> >
> > There are at least two other ways to "enable diffserv." One way would be to
> > just let the hosts set the diffserv bits, and then let the intermediate
> > router do accounting, charging, and maybe rationing. Another way is to use
> > RSVP to convey the requested quality of service, and the user credentials,
> > to the intermediate routers; then, the flow-id can be use for flow
> > classification, and the intermediate routers can on this basis set the
> > diffserv bits however they see fit.
> >
> > -- Christian Huitema
>>[....]

S/MIME Cryptographic Signature

Reply via email to