Subject: Re: Portmanteau reply Re: a), b), c), d), or e)

From: Francis Dupont <[email-masked]>
Date: Sat, 01 Sep 2001 19:43:27 +0200

In your previous mail you wrote:

     | It's the former; if an ISP chooses to disbelieve the upstream ISP,
     | and re-classify the traffic, the semantics of the transport
     | header are exactly the information of interest.
   
   No they're not.   There is nothing at all in any transport header of
   relevance that contains anything in any way related to QoS.
   
=> I agree, the whole stuff about MF re-classification on
the 5/6 tuple seems silly to me.

   For diffserv, there's no out of band signalling, so every packet needs
   to be labelled so it can get the correct processing.

=> so even if MF re-classification on the 5/6 tuple is the wrong
problem we still have to investigate (:-).

   But IPv6 has another way - you can simply request that the sender add
   a new header (more on that in a second), require it to appear immediately
   after the hop-by-hop options (if any, or the IPv6 header otherwise) for
   it to be effective anyway (ie: you look that far, and assume default
   processing if the header doesn't appear there).  In this header you can
   stick all the QoS classification information you're ever going to need.
   That can even look like a transport protocol port number combination if
   you like - just don't expect the port numbers (or even transport protocol)
   to have any relationship at all with the ones the transport protocol or
   its ports that are actually being used.   I'll pick values that generate
   the QoS effects that I desire (which might sometimes be a 1::1 mapping
   from the value actually being used, but also might not be).
   
=> this solution was suggested in the last discussion about how to
do MF classification on the 5/6 tuple at very high speed (I believe this
discussion was initiated by Thomas Eklund). My only concern is simple:
is it a solution for the wrong problem?

Regards

[email-masked]

PS: I sent my mail to Brian before reading your mail... The PHB ID
proposal can (should?) give better options than to put fake protocol/ports
into the QoS option for silly MF classifiers. If the overhead of
the QoS option is acceptable we should have to design smart way
to use it.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Sep 2001 15:08:28 -0500

> the 5/6 tuple seems silly to me.

People do much worse things already, by looking even deeper into
the packet. In practice, I agree that port numbers aren't too much use,
and probably very often only the addresses will be used. The whole
idea Alex and I had was to give IPv6 an advantage by using the flow label
to support more effective MF classification.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Sep 2001 10:17:06 +0200

the packet.

=> I know... I'd like to see how this will work at 10Gbits/s.
On the principle I don't want to have ISPs that I don't trust
to look at the transport header or the payload of my packet.
Of course, if the answer is to use ESP we have only shown
the silliness of the whole thing!

   In practice, I agree that port numbers aren't too much use,
   and probably very often only the addresses will be used. The whole
   idea Alex and I had was to give IPv6 an advantage by using the flow label
   to support more effective MF classification.
   
=> this is what I have understood so even you proposed a PHB ID in fact
alternatives in appendix A are still options...
My concern is that if the MF re-classification on the 5/6 tuple or
worse is given up then your idea will be given up too: should we
discuss about the provision of effective MF classification or
discuss about the MF classification itself?

Regards

PS: this is an architecture issue, I don't know how to solve it
(ask the IAB to move diffserv to historic?)
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Sep 2001 09:45:37 -0500

Francis Dupont wrote:
...
> (ask the IAB to move diffserv to historic?)

I don't think so :-)

Actually the diffserv architecture does not formally require MF classifiers
and does not formally require them to be port/protocol based, although
the 5tuple classifier is cited. If somebody comes up with a better solution
it can be plugged right in.

   Brian

---

From: Alex Conta <[email-masked]>
Date: Thu, 06 Sep 2001 01:31:02 -0400

> it can be plugged right in.

No, no.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 11:30:36 +0200

Actually the diffserv architecture does not formally require MF classifiers
   and does not formally require them to be port/protocol based, although
   the 5tuple classifier is cited.

=> this is my concern: the door is open for stupidity.

   If somebody comes up with a better solution it can be plugged right in.
   
=> perhaps this mailing list is not the good one (diffserv-interest?)
but the fact we have again this discussion shows the issue has to be
fixed ASAP.

Regards