Subject: Re: mbone dvmrp/pim & congestion

From: [email-masked]
Date: Mon, 22 Sep 1997 15:02:56 -0700 (PDT)

[email-masked] (Ran Atkinson) wrote:

|> On Sep 22 18:50, Petri Helenius wrote:
|> } Subject: Re: mbone dvmrp/pim & congestion
|> 
|> % I've always thought that the above is an artifact of the fact that
|> % there is no reasonably scalable and working inter-domain architechture
|> % to be used in the first place, not that a group of users pulling down
|> % megabits of data would be of great concern. (since they can do it
|> % anyway, just with multicast it does less damage)
|> 
|> TCP sessions do MUCH less damage to the network infrastructure than

I'm trying to picture the routers and T-1's overheating from
excessive UDP traffic...  OK, I'm kidding, I know you didn't 
mean that it would actually *damage the infrastructure*, but, 
I think that this is a good place to be very precise.  Yes,
a properly-implemented (not all of them are) slow-start TCP
is self-tuning *end-to-end*, unlike a UDP stream.  In the short 
run, that makes TCP much nicer, because TCP doesn't insert (many)
packets into the network which have to be dropped somewhere in 
the middle due to a congested link, and, when drops and congestion
occur, they occur in the right place - on the congested links.

But, thinking of the long run, today you already have TCP apps 
with multiple streams that allow apps to grab more bandwidth, 
you have TCPs which don't do slow-start properly anyway,
you may even have some TCPs which attempt to modify the 
slow-start algorithm just slightly in order to game the 
system and get a bigger share of the pie.  So, in the long 
run, the real question you are going to have to face up to 
is *fair* resource allocation - dividing up the pie.  The 
fact that you aren't dropping too many packets isn't necessarily
helping a user who is getting poor service.

Billing per-packet has very many drawbacks, as I have pointed
out on a previous message: a packet which is transported when
network congestion is low costs nothing at the margin: it is 
the packet sent when the network is dropping packets that 
costs.  But, congestion changes from minute to minute, and
users are likely to find a minute-by-minute bidding war
unattractive (although, it has been tried on computer systems).

The simplest way to do network resource allocation to limit 
the size of the user's pipe, e.g., to a 28.8 modem or whatever, 
but that, of course, wastes the time of your users.   

So, naturally, you would like to give users bigger pipes, but, 
when contention is high, allocate traffic somehow according
to the level of service the user has paid for.  Queuing is
the general answer, although, I agree that with multicast,
the desired behavior is more subtle to determine.  Should,
for example, multicast groups with very large numbers of 
viewers be allowed to squeeze out all other traffic just
because the multicast delivery is efficient?  On the other
hand, if 100 people want to receive a data stream, their
combined shares should be allocated more bandwidth on a
congested intermediary link, wouldn't you say?  The notion 
of "equity" depends on where the viewers are relative to where
the congested links are.  (Also true of TCP unicast traffic).

|> UDP sessions, because TCP includes congestion avoidance.  Multicast
|> necessarily uses UDP.  Until multicast sessions include some form
|> of reasonable congestion avoidance, there is good reason to fear
|> multicast traffic more than TCP-based unicast traffic.

Ultimately, if your users don't get good service, they will 
switch providers.  If one user or group of users is allowed
to hog the resource, your other users will be unhappy, 
and it won't make any difference if the traffic that pushed 
them out is multicast or not.  Why, for example, should it 
be considered better if a link is totally consumed by 
100 concurrent CU-See-Me sessions than used 10% by a single 
multicast session?

Personally, I think some form of weighted "RED" queuing can 
be created to handle all traffic, including multicast,
although I admit that multicast may make it trickier.

Corrections welcome.

-Hugh LaMaster

  Hugh LaMaster, M/S 258-5,     ASCII Email:  [email-masked]
  NASA Ames Research Center     Or:           [email-masked]
  Moffett Field, CA 94035-1000  No Junkmail:  USC 18 section 2701
  Phone:  415/604-1056          Disclaimer:   Unofficial, personal *opinion*.

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 23 Sep 1997 09:03:02 +0100

Hugh 
 
can i point people at the IRTF RM group now - this discussion (and
several VERY promising solutions) are going on there more effectively
- a meeting last week saw several people cover this excellently...and
hopefully minutes will appear soon with pointers to the various
papers - meanwhile
[email-masked]
will handle join requests and i guess has the list archive...

cheers

 jon