On Wed, 10 Jan 2001, Fred Baker wrote:
> At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote:
> >it be left to the application/user to decide
> >whether they would rather use the spoofer and be exposed to higher failure
> >probability, or just play safe and bypass the spoofer (assume that the use
> >of a spoofer is not mandatory)?
>
> In general, I would agree with that. Now tell me this: do you know that the
> spoofer is there? How do you evade it?
>
well I believe the question is more along the lines of: if ISP X uses
spoofer or caches or whatever to give you better performance(thruput or
security or whatever you are measuring performance as) then you will
continue to use them. If their service to you is unacceptable then
you as the user can choose to switch to ISP Y. The bottom line is
will the free market support for intelligence in the middle applications
be sufficient for them to survive...
if ISP X notices 10 big customers switching to someone else believe me he
will quickly drop spoofing.
if spoofing is invisible to end users and the users dont
get any data losses or problems to complain about...then does it matter
whether spoofing is used or not....is'nt the whole point of spoofing
to get more customers by offering a network with (hopefully) superior
performance than an competitor....
if customers do notice data losses degraded throughput hung connections..
whatever....then they are free to switch to another ISP.
so it is correct to say that the end-users..(okay not applications) do
in a way get to decided whether spoofing is good or not...whether they do
this actively("..I need to call my ISP and find out what they do...") or
passivly("aa...I dont know why my netscape browser hangs every 4th
click.....I hate it...next month I'm switching")
manish karir
> The cases that come quickly to mind are transparent and
> non-transparent web
> caches, Packeteer-style QoS control boxes which fiddle with TCP
> headers, Arrowpoint-etc devices which front-end sets of web servers,
> and so on. I can get around the non-transparent caches (SQuID etc)
> readily enough, but I may not be able to get around the others, and
> may not even know they are there.
>
> In such cases, the statement above is a great sentiment, one I would
> wholeheartedly support, but doesn't seem very practical.
>
>
This archive was generated by hypermail 2b29 : Wed Jan 10 2001 - 10:33:29 EST