Subject: RE: The problem with tagging packets

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Tue, 11 Nov 1997 11:20:45 +0200

On 10 Nov 97 at 10:43 AM, Wu-chang Feng wrote:

>Weighted fair bandwidth sharing in single-bit schemes is done by marking   

>different fractions of a connection's, a machine's, a subnetwork's, etc.   

>packets.  With multiple DP schemes such as SIMA, weighted sharing is   
done
>by encoding the "weight" in each packet.  I think it is possible to have   

>SIMA-like functionality with a single bit by translating the weight
>encoding into a marking fraction.
>
>Wu

Yes, it is possible to encode the DP bits in several packets. Actually,   
we seriously considered that kind of scheme some time ago. We have not   
proposed it because of some problematic issues.

Firstly, it requires that every node keeps track on every individual   
flow. With the current router technology that is, of course, not a big   
problem. However, our intention is to develop a really scalable approach   
which can be based on the use of ATM VPs or some other similar   
technology.

Secondly, it lengthens the reaction time of the system as the node may   
have to wait quite long before it knows the actual drop preference level.   
This not so big problem with pure non-real-time data flows with big   
buffers. However, if we try to integrate real-time flows with relatively   
small bit rate into the same system, the situation is much more   
difficult. As the real-time buffers have to be quite small, the system   
must react quickly - it cannot wait, let say, 10 milliseconds to make out   
the drop preference level of the packet.

So, your proposal may work quite well in current networks based purely on   
router technology and with non-real-time service, but it is not as   
scalable as a system with 3 DP bits in every packet, and it is not as   
appropriate to realize a real-time service.

.. Kalevi

---

From: Roch Guerin <[email-masked]>
Date: Tue, 11 Nov 97 07:28:30 -0500

>appropriate to realize a real-time service.

Kalevi,
I would not implement support for real-time service, or any delay
differentiation for that purpose, using drop precedence.....
A delay precedence semantic seems much more appropriate and natural.
Roch