Re: Email messages: How large is too large?
In message [EMAIL PROTECTED], Valdis.Kletnieks@vt .edu typed: --==_Exmh_-374731876P a) Do you have an incoming anonymous FTP drop *of your own*? b) Are you willing to set up incoming FTP for one file? c) What if you're one of the millions of people who use an ISP that doesn't provide FTP drops? plenty of ISPs offer free web space (e.g. 5M is typical) - for a file of size nMbytes , all you need is to get n/5 internet accounts , run split on the file - hey you could use slightly more (e..g n) and even run a fancy layered fec dithering crypto algorithm and have a file that noone could _remove_ without removing more than 4n sites - its called an "eternity" service and is a possible very valuble service indeed (reliable and also hard for centralized authorities to attack) OK, that doesn't seem to be viable. Let me store it and you pick it up: d) I happen to be lucky enough to have my own workstation. However, you can't FTP to it because I have FTP disabled. If I don't have an FTP drop, you can't pick it up. e) If I didn't have a Web page area big enough to hold the file, how would I send it to you? Remember that many freebie sites put a 5M or 10M quota on the users... Of course, the right answer is something like this: 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT=17366 bytes) (Status: EXPERIMENTAL) However, there's few enough sites running it that it's not really an alternative. Heck, I *know* Rick Troth, and I'm not even running one, mostly due to a lack of anybody else for it to talk to. Perhaps it's time to dust that RFC off and see what can be done with it... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-374731876P Content-Type: application/pgp-signature -BEGIN PGP MESSAGE- Version: 2.6.2 iQCVAwUBOFVSLtQBOOoptg9JAQHU/QQAs9Co7vgq6IElSjIlizIJD9i+vA4VjhNS cObsuiF0rwXHoYdrTlyJKm0FO4Yrs+J5CpPKGRL3ky6sR7FaD32lhg0PKZBlTC4s GkVcNNp8mJoYOIcscf07bRtn0GzyJHtzRxpqaVbK9k0whb5j/Or91CTdnEPU5OAS obDidnOhNfA= =KdSF -END PGP MESSAGE- --==_Exmh_-374731876P-- cheers jon
Re: Email messages: How large is too large?
] From: "Martin Djernaes" [EMAIL PROTECTED] ] I know that the internet were not build for "general use", but it is the ] life of the net today, at it should be the goal for the people ] implementing it (us?). Let us get away from the idea that it should ] always be used the way we implemented it and change our view to how ] would the user like to use it. There is no magic. Users have been demanding the impossible from SMTP on the grounds that they don't understand why not for decades. The same people who wouldn't try to load 10 ton of gravel in the back of their light duty pickup truck expect email to be 99.% reliable, have end-to-end delays of less than 15 seconds 99.% of the time, and to move arbitrarily large files in at most 15 seconds. Just because people want something does not mean that it is possible or even desirable. As long as the fact is that it takes 15 seconds in average and the reliability is 99 or more % I will not blame the user for expecting this functionality from such a service. Our job is to not to tell the user, that what he do is wrong but to make the service usable (I guess that were the reason someone invented MIME in the first place). Personally I would love another solution than encoding you files into a mail (it actual get a size increase of 33%). It's actually worse than that. Instead of demanding a way to move large files, they demand a way to move large email messages, and they cannot understand the distinction. I do not think so - if we could make a transparent way of sending large files, the user would not care if it is a mail or something else. There is just one fact which is in the way for any other solution - as long as the user have a way of sending his/hers files, and it actually works (I mean he/she have a program which make the way of doing it transparent to him/her, and the file get to the desired destination within a reasonably short time) there is not reason seen from the point of the user to get another service. ] If the user would like to transfer 28 MB we should make it possible ] (there is always somebody who is in front of the big group, so I do not ] say that just because one person wants it we have to make it possible). There are scaling problems. Consider how many disk drives an ISP would ... The size issue is there what ever (relay-)service we use! We can try to prevent the usage being to big (why make a BASE64 encoding when we can store it binary etc.). ] If the mail service from today isn't the right solution, we should ] invent a better. If all providers would allow a user to place XX MB via ] FTP on a server, ... Didn't I see mention of something called an "external body"? That notion avoids the scaling problems of requiring that all spool directories and all destination mail directories be large enough when many people decide to forward a 28 MByte Good Times virus. :-) But please tell me which "usable" programs support this function, and what kind of providers offers this service. I have to say that I consider the problem seen from the "dummy" users point of view - he/she have to see the same function from his/hers work place as well as from his/hers home computer (PC? mac?). I guess everybody here would be able to open a ftp server in case of "an extreme big file", but I am not sure that mr. Normal User will be able to do this, and more he will not wait for the receiver to go online to pick it up. -- Regards, Martin Djernæs -- Martin Djernæs[EMAIL PROTECTED] Dipl.-Ing. Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741 Postfach 3246 Fax:+49 (0511) 6747 777 30032 Hannover, Germanyhttp://www.ke-online.de --
Re: Email messages: How large is too large?
[EMAIL PROTECTED] writes: Unfortunately, for most of the Internet users of today, the availability of long-term stable externally-reachable storage is low enough that you usually end up dereferencing a null pointer. It doesn't have to be that way. We'll set up an anonymous FTP site for any user who requests one, at no additional charge. These sites have upload capability and are protected from being used as warez sites. In other words, that user I wouldn't let receive a 28 MB message had an appropriate alternative available. The problem, at least from my perspective, is not large transfers. It is mixing large transfers into a service (email) that most people expect to deliver small messages rapidly. The problem is compounded by most users not having any idea what a MB is. Telling them their mailbox is clogged by a 2MB message conveys nothing to them, but tell them it is clogged by a 25,000-line message and they understand. -- Dick St.Peters, [EMAIL PROTECTED] Gatekeeper, NetHeaven, Saratoga Springs, NY Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/ GlensFalls/LakePlacid/NorthCreek/Plattsburgh/... Oldest Internet service based in the Adirondack-Albany region
Re: Email messages: How large is too large?
In message [EMAIL PROTECTED], "Sp encer Dawkins" writes: I'm thinking that at least some part of the loss-of-transparency issues might get more attention from the nice people who want to put application gateways between themselves and the rest of the world if you point out that this has led to unintended results like 28-Megabyte attachments, because it's MUCH easier to misuse e-mail for file transfer than it is to use message/external bodies that invoke FTP for file transfer for an arbitrary user inside a corporate firewall. The large email issue is mostly a UI issue. To attach a file with most popular mail clients, one simply has to click on a few menues. Little or no external configuration is required. For an external reference, one has to upload the file to some repository, and make sure that mail message is delayed until the upload is complete. Repositories vary in name, access method, authentication, etc., even without firewalls and NAT. (It cannot, in general, be on the user's machine, because dial-up machines aren't connected all the time.) The sender's mail system probably can't do that stuff transparently, because of the authentication issues. And the send needs a progress indicator for the upload of the file as well as the mail. Bottom line: it's not just harder, it's inherently harder, but good UIs would help a lot. --Steve Bellovin
RE: Email messages: How large is too large?
Title: RE: Email messages: How large is too large? Steve, You said this better than I could have - loss of transparency is making it harder for application designers to make correct use of the Internet easier for users, and it wasn't THAT easy to make correct use easy in the FIRST place... Spencer -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 14, 1999 9:39 AM To: Dawkins, Spencer [RICH1:2011-I:EXCH] Cc: [EMAIL PROTECTED] Subject: Re: Email messages: How large is too large? The large email issue is mostly a UI issue. To attach a file with most popular mail clients, one simply has to click on a few menues. Little or no external configuration is required. For an external reference, one has to upload the file to some repository, and make sure that mail message is delayed until the upload is complete. Repositories vary in name, access method, authentication, etc., even without firewalls and NAT. (It cannot, in general, be on the user's machine, because dial-up machines aren't connected all the time.) The sender's mail system probably can't do that stuff transparently, because of the authentication issues. And the send needs a progress indicator for the upload of the file as well as the mail. Bottom line: it's not just harder, it's inherently harder, but good UIs would help a lot. --Steve Bellovin
Re: So transparent I can't even SEE it...
I have always noticed a half day or so time lag between when I get an announcement and when I can find the document using the search engine but the document is always there if you type in the expected URL by hand. I noticed the same problem with Brian's draft but I also noticed the problem on a few other recent drafts which I am pretty sure I tried to pull after the usual time lag would have expired. In other words, I don't think this problem is specific to Brian's draft... John On Dec 14, 7:58am, Spencer Dawkins wrote: Subject: So transparent I can't even SEE it... I was poking around looking for Brian's transparency draft, and noticed that it doesn't come up on the I-D Keyword search for either "Carpenter" or "Transparency". I found it by doing a text search on the Individual Submissions page, but - shouldn't draft-carpenter-transparency-05.txt come up when doing EITHER of the searches I tried? Spencer [ Attachment (application/x-html): 774 bytes Encoded with "quoted-printable" ] -- End of excerpt from Spencer Dawkins
Re: Email messages: How large is too large?
As I recall, the reason that Mime was developed was precisely to allow email to substitute for many file transfers. Before Mime, it was always a bit of an annoyance/embarassment that email could not be used in place of FTP for binary files. Actually, the motivation for developing MIME was internationalization of email. The ability to send content of types other than text was a secondary consideration. But I guess we forgot to take the next big step, redesigning email to properly scale to handling arbitrarily large messages in a relatively graceful manner when necessary. I remain to be convinced that problems handling large messages have much if anything to do with the modern ESMTP protocol. It seems to me that it has a lot more to do with implementation and deployment. Ned
Re: IP network address assignments/allocations information?
Christian Huitema wrote: The first SYN packet gets lost, and the client simply picks another address in the list and tries again. The APIs I've used don't tell me about lost SYN packets (thank goodness); they only tell me if the connection has timed out. So, yes, we have a problem. We need to somehow adapt the TCP stack to survive losses of transit networks. But we should not overstate that problem. It only affects long connections, (a) But long connections are important; they're more efficient (and give the users better performance) than short connections. Modern application protocols are being designed with this in mind. (b) It also affects short connections, just not as often. If Joe User's HTTP connection gets dropped, he'll see "Transfer interrupted" and think there's something wrong with the server (or he'll see a broken image and think the site's HTML is messed up). It would not occur to him that the trouble would be in a transit network; he's probably never heard the term. So he'll come away thinking that the Internet is just plain flaky. it only makes a difference if a connection to a transit provider breaks, Or if the chosen path becomes congested over time. In any cases, there are simple modification to TCP, for which we already have some experience, that could handle the problem. In the long run, once these modifications are in place, we are better off than in the current situation, OK. How long is the long run? How long did it take to get the LFN fixes deployed? They were described in 1989 (RFC-1106); I seem to remember they weren't widely available as of 1994 or so. (My memory may be skewed, though, because one of the machines I was using was running SunOS 4.x, which wasn't being updated much.) -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |They prayed for their fates to be quick, | |[EMAIL PROTECTED]|painless, and, ideally, someone else's. | \==/
Re: Email messages: How large is too large?
At 01:11 PM 12/14/1999 , Ned Freed wrote: But I guess we forgot to take the next big step, redesigning email to properly scale to handling arbitrarily large messages in a relatively graceful manner when necessary. I remain to be convinced that problems handling large messages have much if anything to do with the modern ESMTP protocol. It seems to me that it has a lot more to do with implementation and deployment. Adding to Ned's response -- In fact ESMTP is getting quite good at supporting large file transfers: (0. Pipelining isn't really relevant for bulk transfer, but it doesn't hurt and is at least worth mentioning explicitly so no one thinks it was forgotten.) 1. ESMTP Checkpoint/restart permits recovering from interrupted sessions; too bad it's not well deployed 2. ESMTP Message Size Declaration permits the receiving server to declare its limit 3. MIME Message/Partial permits fragmenting (and reassembling...) large messages so that the Size Declaration can be honored for over-sized messages; too bad reassembly is not well deployed 4. End-user application-to-application negotiation work being done in the Conneg and Fax working groups is emerging; it will permit recipients to inform senders of preferences and constraints. Since it is a highly asynchronous channel, with potentially very high latencies, email is a bit of a challenge for dealing with arbitrary message sizes. The existing and emerging specifications appear to be adequate to the task, but implementation has been slow. That is almost certainly a question of lack of market pull. d/ =-=-=-=-= Dave Crocker [EMAIL PROTECTED] Brandenburg Consulting www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA
Re: IP network address assignments/allocations information?
At 04:29 PM 12/14/99 -0500, John Stracke wrote: it only makes a difference if a connection to a transit provider breaks, Or if the chosen path becomes congested over time. No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. -- Christian Huitema
Re: Email messages: How large is too large?
I remain to be convinced that problems handling large messages have
much if anything to do with the modern ESMTP protocol. It seems to me
that it has a lot more to do with implementation and deployment.
Amen!
A few observations:
Many places depend on mailers which operate as 'parallel to serial' gateways
taking apparently decoupled, asynchronous mail submission and queueing them
into a single linear pass. Therefore while the size of an object for the
submitter has no apparent 'cost' in delay terms, if more than 1 hop exists
between the sender and recipient, then for disinterested third parties there
can be quite substantive issues:
o big mail delays other peoples service
o big mail impacts on service providers in the wider sense who have
no 'contractual obligations' or SLA/QoS signoff with the sender or
the recipient.
End users have a low conciousness of list size. Therefore sending large
attachments to 'mail' can mean a n-oo expansion (ok, not infinity, but
certainly better than 2*n expansion) of data in flow. This has to be set
against sending a 'pointer to pickup' which will only cause m*n expansion
based on total list size actually caring, and fetching the data, coupled
to any cache effects for local recipients who are lists, or otherwise can
optimize the fetchpath.
o you can't easily track or manage the inefficiencies of sending
large mail to lists
o the scaling effects of sending attachments to lists and of
choosing to preference pointers to objects are pretty directly
(inversely?) related to each other in their effect on the network
Bandwith may be getting fatter for some people, but since the total population
on the net is growing worldwide, the distribution of users to bandwidth is
not shifting up the scale at the same rate (modem speeds are lumpy increase,
post-modem access is mired in issues worldwide so its not all cable yet etc)
therefore for a priviledged few @work or @home senders, the cost of submitting
is out of all scale to the cost of reading.
o you can't easily constrain the receiver GUI to avoid d/l of large
objects so you can predict for a list that some % of recipients
are going to be screwed by an apparently benign act
o intermediate mail systems like HotMail impose size limits as a
function of scaling management and commercial imperitives, so
you have a really nasty DOS attack here by blitzing the naieve
with content. This one is real: I support a user on the MPEG
standards track and she lost all mail by (a) going offsite and
(b) .forward-ing to hotmail and (c) being mailed large attachments
from the standards bodies
I think this is about education AND operational deployment:
o Internet driving licences may seem a bit naff, but there
is value in requiring people to migrate to a power-user
status by at least trying to teach them that there are
consequences to using tools in distributed communications
o If there are simple, deployable codechanges which can make
mailers drop in a {reference to object} in place of
{entire content of object} then there is a really really
good reason to try and deploy them.
o There probably is an 80:20 rule here which can be thought
up and promulgated like:
If you know its going to less than 10 people and you
know the datapaths, you can do risky things but if
you think it may go to 100 people and you don't know
who they are, its better to be cautious
o Coupling mail-to-web for archive encourages people to shift
from direct mail access to web is viable for catchup which
leads naturally to using the web as the REAL data repositary
and using mail to point to it. In a short while, you can maybe
shift some practices to 'its easier' instead of 'they require it'
Actually, I think the best example I know of the 'right way' is the
old 'new RFC' email Joyce Reynolds used to post, which had the two variant
MIME attachments for fetch it via FTP and fetch via the web. We just need
more people to be that sensible!
cheers
-George
--
George Michaelson | DSTC Pty Ltd
Email: [EMAIL PROTECTED]| University of Qld 4072
Phone: +61 7 3365 4310| Australia
Fax: +61 7 3365 4311| http://www.dstc.edu.au
RE: whois?
Martin, don't expect things to get better about UCE, your registration information is now available for sale. all registrars are required to sell their whois databases for a maximum of $10K, per the latest ICANN/DOC/NSI agreements. -rick On Tue, 14 Dec 1999, Martin Essenburg wrote: I think it is a good idea because companies are using the whois info as a mailing database for there products. I get a ton of snail mail from this MJE Martin Essenburg MCI WorldCom - Global Accounts East 727-431-5907 Vnet: 977-5907 Pager: 1-888-270-9268 (2way) mailto:[EMAIL PROTECTED] http://sts-east.mcit.com -Original Message- From: Robert G. Ferrell [mailto:[EMAIL PROTECTED]] Sent: Monday, December 13, 1999 1:14 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: whois? I'm just wondering -- my whois command doesn't turn up contact information for domains anymore. What's going on? I get a registrar's name instead NSI changed WHOIS servers on 1 December. Use whois -h whois.networksolutions.com Robert G. Ferrell Internet Technologist National Business Center, US DoI [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
At 02:50 PM 12/14/1999 , Christian Huitema wrote: No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. Only minimally, as long as a TCP connection is tied to an IP address... d/ ps. Christian and I separately suggested changing this, to support IP mobility, a few years ago. =-=-=-=-= Dave Crocker [EMAIL PROTECTED] Brandenburg Consulting www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA
NHRP
Could any body tell me where i can find a tutorial/specification for NHRP ( Next Hop Resolution Protocol). How does it work ? Any idea ?? Thanks Prabhu
Re: NHRP
Could any body tell me where i can find a tutorial/specification for NHRP that is RFC 2332 - you can get the RFC through the IETF web page at www.ietf.org Scott
CDP
Hi, Is CDP (Cisco Discovery Protocol) an IETF draft or RFC? Any other information on discovery protocols or pointers would be greatly appreciated. Thanks, -James
Re: IP network address assignments/allocations information?
At 02:50 PM 12/14/1999 , Christian Huitema wrote: No. This is no different from the present situation. BGP does not recompute routes in case of congestion. It is a problem that we are stuck with today, that multi-address multi-homing actually gives us the hope of solving. Only minimally, as long as a TCP connection is tied to an IP address... d/ ps. Christian and I separately suggested changing this, to support IP mobility, a few years ago. indeed, and something like this appears to have surfaced again, albeit briefly, in the IPNG working group.. see the sep/oct section of http://playground.sun.com/pub/ipng/html/meetings.html particularly, the "Preserving Active TCP Sessions ( pdf ), P. Tattam " - Bill
Re: WAP
WAP is not an IETF activity - it is from the WAP Forum http://www.wapforum.org/
RE: CDP
CDP is a Proprietary protocol , you way also want to look at the RFC 2701 Roger -Original Message- From: James F Dougherty [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, December 14, 1999 8:54 PM To: [EMAIL PROTECTED] Subject:CDP Hi, Is CDP (Cisco Discovery Protocol) an IETF draft or RFC? Any other information on discovery protocols or pointers would be greatly appreciated. Thanks, -James
