Margaret Wasserman wrote:
> There is not way to identify "all packets of a single flow" without
> having a set of fields that identify a unique flow (src addr, dest
> addr and flow label?) PLUS the concept of a flow lifetime.
> Otherwise, you may end up dropping packets that belong to a later
> flow that just happens to share the same flow label.

No argument, but why is that a problem? If a router is managing queue
congestion by dropping all packets between src/dst with a specific flow
label, why would it matter that a subsiquent flow was affected? In this
context the lifetime that matters is the period of congestion, and we
really don't want the router maintaining state for any longer than that
if it is not already participating in a signalling scheme.

> Why would we want to restrict possible flow-management mechanisms in
> this (somewhat arbitrary) way?  I think that the question of whether
> the flow label can be modified en route should be left to the
> specific flow-management mechanism.

Absolutely NOT!!! We already have too many mechanisms that
allow/encourage the value to be modified in route, and this field is the
only one we have left that can have meaning end-to-end. THERE IS NO
REASON TO CREATE ANOTHER ONE! We need to take an architectural stand
here and say that if you want to modify something along the path use the
DSCP or MPLS or VPN or GRE or your favorite random scheme. The
host/application needs a way to inform anyone along the path that may
care, 'this set of packets belong together'. If we allow violation of
that principle simply because the control freaks want to be able to
modify anything and everything, we might as well give up on ever having
applications that expect more than random treatment from the network.

Tony





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