Inria, Rennes, France

30 October 2000
===============

Met with Laurent Toutain (IPv6 and diffserv guy), Jean Mary Pointte (oid)
David Ros and Octavio (Ph.D. student which is almost ready, and
implemented a lot of the DiffServ architecture in BSD). All are in the
ARMOR project of INRIA. After a small introduction to each other,
where I explained what our group does, we talked about what they do
and possible cooperation between our groups

- Dante DiffServ/IPv6 experimental network

The Dante network is a pan European research network, connecting the
various national research networks, which is used (among other things)
for experimenting with new network technologies. It is used for IPv6
conformance and interoperability testing , differentiated services
testing, among other things.  (see also www.dante.net).

Laurent is doing DS conformance tests, as well as interoperability
tests. 

       It would be interesting to participate in this network and see
how the diffserv architecture/implementations can work with multiple
domains and a more wide area network. This would also allow us to
experiment with combining the diffserv architecture with something
like a smil switch based on bandwidth, but dynamically.


- Octavio's presentation

Octavio gave a presentation about his work on Differentiated services,
and especially the Assured Forwarding (AF) phb, which is easily
implementable on todays networks. The other phb, Expedited Forwarding
(EF) is hard to implement over broader networks, but can give better
qos guarantees. See also blue note 34 about networks.

1 drop precedence levels

    AF distinguishes between 4 different classes which each can be
given a number of resources (bandwidth, buffers-pace), and
within each class each packet is given a drop precedence. This drop
precedence indicates the relative importance of the packet in the
class. If packets from a class need to be dropped, it will drop
packets with a higher precedence with a higher likelihood than those
with a lower drop precedence value.

2 TCP vs UDP

TCP streams have an automatic handling of congestion. When a packet is
dropped, the sending node is notified to lower it's packet window (and
thus effectively lowering the sending rate). UDP streams have no such
congestion control, the sending node gets no notification that the
packet has been dropped, and thus will starve any TCP streams which
compete for the same bandwidth.
 
3 token buckets and relabeling

Instead of just dropping the packets which cannot be forwarded by the
DS node in question (due to bandwidth and/or buffer limitations)
according to the AF spec, he suggests relabeling packets which are not
within the bandwidth limitations for a class. When the stream is not
within the bandwidth specification of the class, the least important
packets are dropped (the red packets) and the more important packets
(green and yellow) are remarked into these kinds of packets. This is
done at the ds ingress interface so it can scale (fe at the sending
server). 


4 demonstration of mpeg video and audio streams

I was demonstrated the receiving of a video (mpeg1) stream with and
without the above described system, with a packet loss of 25% (so each
packet had a chance of .25 of being dropped). Since each packet had
the same chance of being dropped (whether it is an i(complete) or p
(based on previous images) packet). The video quality resulting from
this stream was quite low. However when using the diffserv
architecture, the packets were marked with importance (the i packets
had a lower drop precedence than the p packets, etc). This resulted in
a much better feel for the video. The same holds for audio, where the
most significant part of each byte was sent with a low drop
precedence, and the least significant part was sent with high drop
precedence.
 
- Middle ware for DiffServ and application interaction

Octavio has some students who will work on a framework/middle-ware
system that will allow easy implementation of the demonstrated
capabilities. One would only have to mark the importance of a given
set of data (the most significant part of the bytes in the audio u-law
stream, the difference between the I,P and B frames in mpeg streams
etc) and the middle-ware will take care of labeling the packets at the
sending end and recreating the original stream (as expected by the
application).

What could be interesting for us is the feedback such a framework could
give to the application sending the stream. So instead of just sending
half of the most important information in case of severe congestion
(which will not be useful to the receiver of the stream), we could
switch to another media--object which would have the same information
in it (so instead of an audio stream describing a painting, send just
the text for the reader to view, for example).

This would require the middle ware layer to give feedback to the
multimedia server (or client) application which informs it about the
current network capabilities. This would allow one to implement the
above idea (among others).


Frank Cornelissen