Subject: Re: IP Broadcast

From: [email-masked] (Hiroshi Esaki)
Date: Mon, 24 Oct 1994 15:44:04 -0400

>> FIFO with big buffer will be fair for every body, I think. 

  jh> are you suggesting that the current internet is fair for everybody?  my
  jh> experience is contrary.  the current internet favours those who send
  jh> more and don't care about congestion.  i would like the ubr give fair
  jh> share for both tcp and udp streams, which can't be accomplished just by
  jh> big buffers.

You may be right. 
Current Internet may not offer fair service from your point of view.
But, you could see from the different view, you could try to access
whenever you want and what speed (bit rate) you want. 
Yes, low speed packet will suffer from the high speed packet 
flow. But, both flow will suffer with the same propability. 
There are many matrics to measure the fairness. 
Of course, in ATM Forum (TM-WG), the available bandwidth 
for every packet flow is fair in congestion state is the 
definition of fairness. 

Hiroshi Esaki

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 Oct 94 13:00:00 +0000

>   FIFO with big buffer will be faur for every body, I think. 
 >are you suggesting that the current internet is fair for everybody?  my
 >experience is contrary.  the current internet favours those who send
 >more and don't care about congestion.  i would like the ubr give fair
 >share for both tcp and udp streams, which can't be accomplished just by
 >big buffers.
 
juha

the Internet is not fair for a much more subtle reason than you say

scott shenker's papers on the matter say that there are games you can
play with a FIFO scheduler that mean you can beat it unfairly - not
simply by sending and not cvaring about congestion - if you do that,m
the internet is fairly unfair....

a round robin opportunity per source scheduler is fair....but hard to
to implement perfectly in a WAN and keep high utilisation....all the 
different ways of spreading traffic info around the net suffer from
delay, so...

if you do this well, i don't understand what then differentiates UBR
from ABR (except perhaps total overload behaviour where UBR could do
loss randomly, whereas ABR will queue things up more...but that is a
disadvatage for data using TCP over ABR....and leads me to think why
not use UBR for best effort video and TCP, and VBR anything else...etc
etc - anyhow, i think the ATM class of service people would do well to
adopt the int-serv simpler model of scheudling classes...though there
are some subtle grey areas between service and implementation that i
still don't get...

 jon