Subject: RE: Qry on Traffic Policing (IPv6 header changes)

From: Jim Fleming <[email-masked]>
Date: Wed, 11 Jun 1997 11:55:01 -0500

On Wednesday, June 11, 1997 3:59 AM, Scott Bradner[SMTP:[email-masked]] wrote:
@ > So, I recommend that one bit from IPv6 version field is taken to this
@ > kind of drop bit
@ 
@ this sort of issue is not an easy one - there has been quite a bit
@ of discussion in many forums about how best to deal with excess
@ traffic - a discard OK bit is one of a number of options 
@ 
@ at this time it seems to me that the community does not have enough 
@ understanding of the complexities in this area and more research
@ is needed before we should be off reserving bits.
@ 

I agree. It is hard to design good protocols bit by bit.

It is sort of a shame that more research platforms
do not exist to allow for the global testing of new
ideas. There are companies willing to make investments
in these efforts but in some cases they are prevented
from proceeding because they do not have access
to basic Internet resources. The universities control
those resources and use the NSF to prevent commercial
access.

Despite these repressive policies of the Internet
leadership, new frontiers in protocol design still
continue behind the scenes. At some point the
commercial interests in new and better approaches
will outweigh the academic's ability to control the
resources.

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

---

From: Harri Hakulinen NRC/Tre <[email-masked]>
Date: Thu, 12 Jun 1997 12:30:05 +0200

> Steve Deering wrote:
> > > Petkos wrote:
> > > However, I don't believe that: they send it anyway.
> >
> > Without router support for drop priority, the transmission of excess
> > packets into a congestion point causes the "more important" packets
> > to be equally vulnerable to loss as the "less important" packets.

Yes, of course. Do you mean that you don't know any company, that would
be interested to support this in routers ;)

> Steve wrote:
> > Thus, there is an incentive for the applications to be designed 
> > not to send less important packets into congested paths. If they
> > "send them anyway", they will harm not only other flows in the 
> > Internet, but also their own "more important" traffic.

I have seen some applications that currently send ALL their packets
TWICE or so to increase receiving probability ! 

I don't know how well this works in the long run, but I know that
you can't do that, if you have e.g. GSM-based low speed PPP-link
to your videophone/laptop   

( it may work "well" with xDSL or similar fast links, if you are
  only thinking yourself (and if all don't have as fast links) ).

>Dimitry says:
> Is it that easy?! Does the application always know how much of its
> data can reach the destination at any particular moment if
> statistical multiplexing is used?
> Matt says:
> TCP does a fair job of figuring this out.  If you get to design your
> protocol today from scratch, you should be able to do it even more
> efficiently, yes?  Or am I naive?
> Steven L. Blake wrote:  
> Even if video applications are good at estimating the instantaneous
> path bandwidth and adjusting their compression rate correspondingly,
> packets will still get clobbered due to transient congestion 
> (or at sustained congestion onset), which occurs on timescales 
> shorter than the application's congestion reaction time. 
...
> Also, the burstiness of (shaped) VBR video is such that the rate
> can vary by a factor of 3-5 within one frame period (~ 33 msec). 
> Allowing video applications to burst periodically with 2 levels 
> of loss priority is a very efficient means of statistically 
> multiplexing video sources while offering good delivery probability
> for enhancement-layer packets and excellent delivery probability
> for base-layer packets.

I wonder if TCP or any congestion control algorithm is capable 
to handle this kind of bursts in efficient and fast enough way.

I also wonder, that now when video people have developed VBR type
codecs that should naturally fit to current Internet ( maybe with
drop priority bit ), then IP people are trying to classify traffic
and make reservations.

Doesn't seem to make any sence to me.

-- 
[email-masked]
Video lab/Tampere/Finland