Re: Melting the Internet?

Joseph Kahan (jkahan@phoenix.phoenix.net)
Wed, 3 May 1995 21:34:52 -0500 (CDT)


I have been watching this Internet "battle" from the side line for
several days now and would like to know what is your goal is?

I thought it was to get Cornell to discuss their reasons from selecting
UDP over TCP, but Dick answered that question very well, I thought.

Then I thought it was to flex your knowledge of protocols, but you only
viewed one side of the coin and never gave proper thought to why Cornell
might have selected UDP over TCP. Your scenarios for flow control only
outlined a solution utilizing the protocol layer. But tell me, what
is so wrong with allowing the network or node at the physical layer to
provide a service. Also your scenarios using modems are an extreme that
I think Cornell never designed the application for. Even in their read
me file, they clearly state it purpose as an Internet video-conferencing
application. Only recently, with the latest modem technology, have people
even considered modem connections to take the place of on-line internet
service. I really think your reaching, when you use this type of
scenario. A clear solution here is don't use a modem and you won't loose
soo much data or request the sender to restrict his bandwidth as Dick
suggested.

So after all of that opinion, I still don't understand your goal
pertaining to this subject. If Cornell didn't answer your points or issues,
then restate them as direct questions and try again. If they
did, then great we all just learn why Cornell selected UDP over TCP.

Sorry, I just don't understand what was wrong with the responce sent
out by Cornell.

On Wed, 3 May 1995, Sean Foderaro wrote:
> I received a number of replies to my message, some private and some to
> the mailing list. I'll address the main items brought up:
>
> Q. TCP is bad since it does packet retransmission (if necessary), and
> why retransmit old data?
>
> A. If TCP has to resort to retransmission then it is because the
> network dropped the packet (or acknowledgement), which means that
> the net can't support your packet rate at this time. The net
> is telling you to slow down. If you were sending UDP packets they
> would likely get dropped too. What is worse, retranmitting an old
> packet or sending a new one that will get dropped anyway?
> Basically this is flow control in action and flow control is a good
> thing.
>
> The current CU-SeeMe using UDP doesn't know whether a packet reached
> its destination or not so it is doing continuous retransmission of
> unchanged parts of the video image. Of course it does this at
> a slower rate. If TCP were used then these background
> retransmissions would be totally unnecessary.
>
> So the situation is:
> tcp - retranmission when you're sending faster than the net can
> handle at this moment.
> udp - continuous retransmission at a low rate.
>
> One could design a system using UDP that let the sender know
> what had to be retransmitted, basically duplicating those pieces
> of TCP that are appropriate to real-time data transmission
> (such as packet acknowledgement and flow control). It appears
> that that is what is happening at CU. I certainly support that.
> Once that work is *done* I'd support using UDP for transmission.
> Until the point that that software is working, it is my
> humble opinion that the version of CU-SeeMe freely available to
> the folks on the internet should use the sub-optimal TCP protocol.
> That way people who don't know what they are doing don't hurt
> themselves or others.
>
> Q. Uh, how is it that UDP gives a CuSeeMe user unfair advantage over any other
> TCP internet user?
>
> A. Imagine that you've got a 10 inch water pipe (representing a
> 10mbps network) connected to a 5 inch pipe (representing a
> 1 mbps net connection) connected to a garden hose (representing my
> little 14.4kbps connection)
> [obviously the scale is off but that doesn't matter].
>
> Now you start to send me water (represening UDP packets) at a huge rate.
> Water will start to flow out of the garden hose but not fast
> enough so the 5 inch pipe will fill up and then the 10 inch
> pipe will fill up. Soon the pressure valves on the pipes
> will open up and water will spray out (representing packets being
> dropped).
>
> So while I'm still getting data through my garden pipe at 14.4kbps
> you've managed to congest the whole network preventing other people
> from using it.
>
> Now let's use TCP rather than UDP in the scenario: With TCP you
> start sending water though the pipe for a few seconds but stop
> until I tell you that I've received the first part of it
> then you send some more. When we reach a steady-state
> the amount of water flowing
> through the 10 inch pipe is the same as the amount going though
> the 5 inch pipe which is the same as the amount going through
> the garden hose. So there is plenty of space in the 10 inch and
> 5 inch pipes for other people to send their water.
> This is what I meant by being fair to other TCP users.
>
> Q. what about this following statement?
> So if you're on a slow PPP
> connection, the reflector could be sending you an
> 80 kbps stream and you'd only get about 23 kpbs
> on a 28.8 connection. The rest of the data just expires
> once its TTL (time-to-live) is up.
>
> A. As my scenario above described, what would happen is that the
> data would get stuck in the memory of the machine responsible
> for forwarding the packets from the fast network (that can support
> the 80kbps) to the slow network (the 28.8 connection).
> After the memory filled up further incoming ip packets would simply be
> dropped. The packets in the forwarding machine's memory
> would never expire due to the TTL field. That field exists only
> to prevent router loops and is decremented each time a packet
> is forwarded, it has no relation to wall clock time.
>
> The effect is that newer incoming video frames will be dropped by the
> forwarding machine while it slowly delivers old video frames
> that are already in its memory.
>
> Q. You can't do TCP multicasting.
>
> A. Agreed. Multicasting is a good thing and is internet-friendly.
> If CU-SeeMe only worked for people connected to the multicasting
> backbone it would cut out a lot of users (like me for example)
> but it would be much kinder to the internet.
>
> My statement about CU-SeeMe being internet unfriendly only applied
> to the current version (since it was this version that people
> expressed concern about publicizing via a Usenet group).
> I believe that the folks at CU *will* come up with a version that
> is internet-friendly