Christian,
I still believe that "bits are bits". As you pointed out, there is no
certainty that a packet to port 80 will carry HTTP. Therefore we should not
pretend to know. Any classification based on this "make believe" is
inherently flawed (IHO).
The DSCP (for diffserv) and address + flow label (for intserv) are all that
is needed for determining the right treatment for the packet.
Information theory wise, the port number stuff you propose is either
redundant or a mistake (the latter in the case of ESP with non-NULL
encryption).
The last thing the Internet needs is "content based charging" for transport,
or "good QoS for supported (read $$$) applications only", both scenarios
likely if the scheme you propose would be in place.
Then again, I might be wrong :-)
Jarno
> -----Original Message-----
> From: ext Christian Huitema [mailto:[EMAIL PROTECTED]]
> Sent: 23. elokuuta 2001 3:49
> To: Brian E Carpenter
> Cc: ipng
> Subject: RE: Higher level question about flow label
>
>
> > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> > > I think the WG needs to decide once and for all whether the flow
> label
> > is
> > > a) a CATNIP or MPLS-like routing handle
> > > or b) a QOS hint for intserv only
> > > or c) a QOS hint for intserv and diffserv
> > > or d) a waste of bits
>
> I think that the most useful use is probably (c). Option (a) is not
> terribly interesting: if you want to do MPLS, just insert an MPLS
> header; MP in MPLS stands for multi-protocol, which means that MPLS is
> always going to have a "layer of indirection" for v4, v6, and whatever
> else the ISP wants to run on it. Option (b) really means "a set of
> random bits" and is not terribly useful either: it would require that
> the routers trusts the random generation in the hosts, which is not
> going to happen (the trust, I mean.)
>
> Option (c) really means "tell me something useful about the content of
> the packet so I can use it for classification." Suppose I
> place here the
> port number that identifies the service, e.g. 25 for mail, 80 for web,
> etc., plus an indication of whether this is UDP or TCP. This plus the
> addresses would enable some easy filtering into intserv or diffserv
> classifications, without requiring that the router go deep into the
> header chain. It would enable easy traffic statistics. It
> would be easy
> to implement for the host (pick the lowest of dest or source port.) It
> would work even if the packet is encrypted. We could reserve
> values for
> specific traffics, e.g. RTP-audio, RTP-video. It would work even if we
> use ESP. From an information theory point of view, this looks
> much more
> useful than either random bits or null values.
>
> Indeed, the bits will have to be set by the host. But then, so are the
> port numbers. Nothing prevent cooperating hosts from running NFS over
> port 80... In fact, if the router is willing to inspect the
> full header
> chain, it could rewrite the bits to a "trusted" value. Also,
> some hosts
> may not be willing to provide the information, e.g. when they actually
> want to hide the nature of the encrypted traffic; these hosts
> could use
> a null field, which would be classified to some default rule by the
> diffserv filters (you cannot have it both ways.)
>
> Count my vote for (c).
>
> -- Christian Huitema
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
