The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1994-Aug> msg00004



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Undeliverable Message

  • From: MAILER-DAEMON@hcs.tlh.fl.us
  • From: MAILER-DAEMON@hcs.tlh.fl.us
  • Date: Thu, 11 Aug 1994 18:55:30 -0400
  • Date: Thu, 11 Aug 1994 18:55:30 -0400
  • X-Incognito-format: VERSION=1.60g ENCRYPTED=NO
  • X-Incognito-SN: 369

To:            rolc@maelstrom.timeplex.com,ip-atm@matmos.hpl.hp.com
Cc:            malis@maelstrom.timeplex.com,jhalpern@newbridge.com
Subject:       rolc and ip/atm multicasting

Message not delivered to recipients below.  Press F1 for help with VNM
error codes.               

	VNM3043:  Jehu Westmark@Support@HCS

------------------  Error number Explanation Follows -------------------

VNM3043 -- MAILBOX IS FULL.
VNM3043 -- MAILBOX IS FULL.

   The message cannot be delivered because the
   recipient's mailbox contains the maximum number of 
   messages, as set by the system administrator.  The
   recipient must delete some messages before any
   other messages can be delivered.
   
   The message limit for a user's mailbox is 10,000. 
   The default message limit is 1000 messages. 
   Administrators can set message limits using the Mailbox 
   Administrators can set message limits using the Mailbox 
   Settings function available in the Manage User menu 
   (MUSER). The 10,000 message limit is the maximum allowed 
   by the Mail program.

   When a user's mailbox reaches the limit, the 
   user must delete some of the messages before 
   the mailbox can accept any more incoming messages.


----------------------  Original Message Follows  ----------------------

[My apologies to those of you receiving this twice - I realize there
is quite a bit of overlap between the two lists.]

For those of you not on the ip-atm list, there has been some
discussion there about doing rolc-like optimization of IP multicast
routing when layered over ATM multicasting.
routing when layered over ATM multicasting.

At present, the rolc WG is working on optimizing unicast datagram flow
At present, the rolc WG is working on optimizing unicast datagram flow
over large link-layer networks (ATM or otherwise) that have an IP
over large link-layer networks (ATM or otherwise) that have an IP
routing topology overlaid on them in other than a simple one-one
manner.  We have not discussed multicast flows at all in the WG, and
there is reasonable doubt whether it is within the current charter to
do so.

The biggest problem is that rolc is trying to find a network-layer
solution that works over arbitrary link-layer networks, and there is
so little multicasting commonality between different link layer
technologies (when it is even supported) that finding a general
solution may not be possible (other than datagram replication at the
network layer, of course :-) ).

Even if the WG decides that it would like to tackle multicasting,
realizing that different solutions may be required for the various
link layer technologies, no WG member has to date either suggested
this work be tackled or contributed any ideas on how to do it.

So, this message is both a poll and a solicitation:

1. Do people think the rolc WG should include multicasting in its
   charter?

2. If yes, do people feel it is OK to have link-layer-specific
   multicasting solutions?  Or carried to an extreme, one solution for
   ATM Forum UNI 3.0, a second for 3.1, a third for 4.0, and so on,
   ATM Forum UNI 3.0, a second for 3.1, a third for 4.0, and so on,
   given that they each provide different ATM multicasting capabilities?
   given that they each provide different ATM multicasting capabilities?

3. Are there any volunteers out there to work on a draft (or drafts)
3. Are there any volunteers out there to work on a draft (or drafts)
   on how to optimize IPv4 [and, for the future, IPng] multicast flows
   over link layers that support their own multicasting facilities?
   Again, this would concentrate on the case where the link layer net
   Again, this would concentrate on the case where the link layer net
   has an arbitrary IP topology overlay; groups like ip-atm will work
   on the one-one case (one such draft has already appeared on the
   ip-atm list).

One important point: this work will, of necessity, be separate from
the current NHRP draft, so we can get a unicast solution out as soon
as possible.

Please, send replies ONLY to rolc@maelstrom.timeplex.com.  The ip-atm
list has enough mail as it is!

Thanks,
Andy
Andy