Subject: Re: Some words from the cochairs...

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Nov 94 12:57:14 -0500

From: Curtis Villamizar <[email-masked]>

    NFS over IP is notorious for it's terrible performance over WANs.
    That is one reason why BSD offers NFS over TCP.
    Appleshare and IPX also run poorly over WANs.  They certainly don't
    share bandwidth well.
    ...
    There is no native AppleShare/IPX/SNA/NetBIOS on the Internet and IMO
    this is a good thing.

The problem with NFS/Appletalk/etc is that they don't have any resource
allocation architecture; i.e. the feedback from resource-limited environments,
and the resource consumption control mechanism that feedback goes into, is not
there. It's thus no particular surprise they don't work well in resource
limited environments. TCP's VJCC may be a congestion control mechanism, but
there's an implicit resource allocation strategy hiding in there.

This thread has tickled some very old memories, in that when I wrote the first
multiprotocol router back in 1979 or so, one of the things I worried about was
how to share bandwidth/processing power/etc between multiple protocols,
particularly if one implemented resource allocation, and one didn't. I didn't
get very far toward a solution, mostly because there was no larger resource
allocation architecture at that point. I did wind up controlling buffers,
thereby implicity controlling the other resources needed to process and
transmit them, but that was pretty minimal.

The resource allocation architecture here is going to have to, as a practical
matter, operate in such regimes, with uncontrolled "partners". However, I
don't see the solution as much harder than other problems here, since it's
basically the same problem as sharing resources between non-controlled
applications (such as NFS), and controlled applications (e.g. voice), or the
solution to applying the resource allocation architecture to networks such
as Ethernet that don't support allocations.

In other words, the mechanism in multi-protocol routers that support resource
allocation *cannot* be IP (or TCP, within IP) specific, unless you're willing
to live with limited abilty to make guarantees, such as you suffer on
Ethernets. It has to be a broad framework into while all protocol forwarders
fit.

	Noel

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Nov 1994 14:09:28 -0500

> Ethernets. It has to be a broad framework into while all protocol forwarders

Noel,

TCP over IP is our target for elastic traffic.  RSVP over IP is our
target for traffic that requires a reservation.  Right?  I don't see
any other candidate that allow hetergeneous networks to be supported.

Noel - since you brought up ethernet again, did you take a look at the
paragraph on RSVP (++?) over ethernet.  I haven't seen any comments on
the feasibility of this?

    There is nothing to prevent us from asking that RSVP reservations be
    queued ahead of elastic traffic.  If they get slowed down by
    collisions on an ethernet, that is not terrible.  It may still be
    possible to configure the borders of an ethernet infrastructure to
    limit the number reservations to make it possible to keep traffic
    flowing.  Perhaps we just bhave to be a bit more creative, like
    defining an ALL_RSVP_ROUTERS multicast address and a protocol to
    coordinate and limit the amount of RSVP reserved traffic on any
    particular segment, which would work well enough.  We can certainly
    also provide guidance to improve the handling of elastic traffic on
    ethernets and maybe prevent future ethernet cards with a total of 4 kB
    of memory on card.

Any comments on the idea of an ALL_RSVP_ROUTERS multicast address on
the local segment (like the OSPF ALL_ROUTERS, just local with an IP
TTL of 1) on which all routers making RSVP reservations can limit the
flow into the broadcast network segment.  Perhaps elastic traffic can
also be artificially deferred slightly by routers or hosts with no
RSVP packets but seeing a rising collision rate (and willing to
cooperate), further increasing the probability of not losing the RSVP
traffic on the segment.  Of course, smart hubs that are essentially
point to point works too - but a solution that works moderately well
but not perfectly on a true broadcast media wouldn't hurt.

Curtis

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 10 Nov 94 09:01:23 +0000

>and the resource consumption control mechanism that feedback goes into, is not

the problems with the pre-TCP versions of NFS etc is that they had no
idea of 'sharing' the net - the original designers felt "ethernet:
thats fast enough for anyone and everyone". as the workstation/server
has now hit the point that a saingle pair can lock up an entire fddi,
the idea has become a tad obsolete....as wide are nets became about as
fast as an ethernet recently, peope contemplated dfoing the worst
possible thing....runing udp based applications over a virtual
ethernet (the internet) which doesn't even have carrier
sense/collision detection coz the delay would be too high:-)
[actually, tcp's loss/fast retransmit is a sort of simulation of how
to do virtual shared CSMA/CD .... there's probablty a smart paper in
here showing what the best possible throughput for the wohle internet
would be based on TCP conenction arrival rates and all doing slow
start or not....see below...

 >there's an implicit resource allocation strategy hiding in there.
 
no - TCP has a model of "given least information, how do we closest
approximate fair share" - it is very subtle, becvause it includes a
meta-game theory which says 
"if everyone weas trying to choose an algorithm to achiee this same
goal, then what should i choose [being like them] to get the best for
me"

the answer turns out (without reservation) to be van's scheme....

 jon