What is best protocol which gives more speed then TCP for low bandwidth networks

What is best protocol which gives more speed then TCP for low bandwidth
networks
Example: for internet though GPRS ( 3 to 50 kbps)

sandeep wrote:
> What is best protocol which gives more speed then TCP for low bandwidth
> networks
> Example: for internet though GPRS ( 3 to 50 kbps)
>

You can't use 'internet' without TCP/IP. UDP is faster, but it has no
error recover and ordering mechanism, but there is no such thing as
'internet' over UDP.

Vincent

Vincent van Beveren wrote:
> sandeep wrote:
> > What is best protocol which gives more speed then TCP for low bandwidth
> > networks
> > Example: for internet though GPRS ( 3 to 50 kbps)
> >
>
> You can't use 'internet' without TCP/IP. UDP is faster, but it has no
> error recover and ordering mechanism, but there is no such thing as
> 'internet' over UDP.
>
> Vincent

Sandeep,

GPRS uses IP for addressing. If you want to talk to existing GPRS
installations, you need to use IP. If you have an Amateur Radio
license and you want to talk to a couple limited stations which use
your own networking protocol, then you need to start with the raw
packets that GPRS uses, which would be similar to starting with
Ethernet packets if you were using ethernet cards. You could implement
your own protocol over that if you want, but I somehow suspect it will
look a whole lot like IP when you get done, and you would have to make
a compelling argument to change how GPRS works to any of your buddies.
Or you could make a gateway I guess.

Vincent van Beveren wrote:
> sandeep wrote:
> > What is best protocol which gives more speed then TCP for low bandwidth
> > networks
> > Example: for internet though GPRS ( 3 to 50 kbps)
> >
>
> You can't use 'internet' without TCP/IP. UDP is faster, but it has no
> error recover and ordering mechanism, but there is no such thing as
> 'internet' over UDP.
>
> Vincent

I want reliable data Transmission also so if I use UDP more
retransmission of lost data so I think it will not give much faster for
low speed networks.
Is there any protocol which gives reliable then UDP and fast data
transmission then TCP .

sandeep wrote:
>
> I want reliable data Transmission also so if I use UDP more
> retransmission of lost data so I think it will not give much faster for
> low speed networks.
> Is there any protocol which gives reliable then UDP and fast data
> transmission then TCP .

Sandeep,

TCP is exactly what you're asking about. As I said, IP is the base
used for the medium you're using. UDP is a connectionless protocol
which has no retransmission. TCP is essentially the same thing only
with "guaranteed" packet delivery.

You might consider tinkering with the packet size to cut down on
overhead, but really I think TCP is what you're going to wind up with
unless you roll your own. If you maximize the packet size then the
header record takes a lower percentage of the bandwidth.

On 26 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, sandeep wrote:

>Vincent van Beveren wrote:

>> sandeep wrote:

>>> What is best protocol which gives more speed then TCP for low bandwidth
>>> networks
>>> Example: for internet though GPRS ( 3 to 50 kbps)

This sounds like a question from a clueless boss who has no concept of
technical reality. It also has virtually nothing to do with Linux, but
I see you already multiposted the same question to comp.protocols.tcp-ip.

>> You can't use 'internet' without TCP/IP. UDP is faster, but it has no
>> error recover and ordering mechanism, but there is no such thing as
>> 'internet' over UDP.

Well, that's not _entirely_ true, but from a practical standpoint it is.
See http://www.iana.org/assignments/protocol-numbers It's _highly_
unlikely, but you could find Appletalk, Novell IPX, Xerox XNS or even
Banyan Vines inside an IP packet - not that anyone would be likely to
know WTF it is, or what to do with the packet other than send back an
ICMP Type 3 Code 2 (_if_you're_lucky_) while they dump it on the ground.

>I want reliable data Transmission also so if I use UDP more
>retransmission of lost data so I think it will not give much faster for
>low speed networks.

Depends on how crappy the link is. IP _itself_ is unreliable by
definition.

>Is there any protocol which gives reliable then UDP and fast data
>transmission then TCP .

The only way you are going to speed up transmission is to reduce the
amount of stuff you are transmitting. If you are going to transmit
a jpeg of your favorite what-ever, it's already compressed, so the _data_
can't be reduced any further. That leaves the headers - 40 bytes minimum
(64 max) for IP and the same for TCP. And you must remember than any
scheme you come up with to reduce the headers size is ONLY going to work
between endpoints you control - because the rest of the world won't know
what your shortened packet is (and will therefore discard it).

So, have a look at RFC0791 and RFC0793, and see what you think you can
do without from those headers.

0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)

0793 Transmission Control Protocol. J. Postel. September 1981.
(Format: TXT=172710 bytes) (Updated by RFC3168) (Also STD0007)
(Status: STANDARD)

In theory, you might consider Van Jacobson header compression

1144 Compressing TCP/IP headers for low-speed serial links. V.
Jacobson. February 1990. (Format: TXT=120959, PS=534729, PDF=255616
bytes) (Status: PROPOSED STANDARD)

but that only works over individual links (not end-to-end), and even if it
compressed everything in the headers down to a single byte, that will only
reduce a 1460 byte data packet (1500 bytes less IP and TCP headers) down
to 1461 bytes - a saving of 19 bytes (about 2.5 percent). That reduction
also only occurs on _established_ connections. You can't use VJ until the
connection is fully up.

You might want to ask the boss why he thinks you can fit six cubic meters
of stuff into a sack measuring 0.5 x 0.5 x 0.5 meters. Someone has a
_severe_ lack of concept.

Old guy

Moe Trin wrote:
> This sounds like a question from a clueless boss who has no concept of
> technical reality. It also has virtually nothing to do with Linux, but
> I see you already multiposted the same question to comp.protocols.tcp-ip.

Why does it always need to take this tone?

> >> You can't use 'internet' without TCP/IP. UDP is faster, but it has no
> >> error recover and ordering mechanism, but there is no such thing as
> >> 'internet' over UDP.
>
> Well, that's not _entirely_ true, but from a practical standpoint it is.
> See http://www.iana.org/assignments/protocol-numbers It's _highly_
> unlikely, but you could find Appletalk, Novell IPX, Xerox XNS or even
> Banyan Vines inside an IP packet - not that anyone would be likely to
> know WTF it is, or what to do with the packet other than send back an
> ICMP Type 3 Code 2 (_if_you're_lucky_) while they dump it on the ground.

What you're describing is still IP traffic in every sense that matters.
Whatever protocol is nested inside is just data, and the other end
will either know what to do with it or not. Tunnelling an additional
protocol inside your packet is NOT a way to reduce overhead. GPRS uses
IP as a base standard, so no matter what he's going to have IP.

> >Is there any protocol which gives reliable then UDP and fast data
> >transmission then TCP .
>
> The only way you are going to speed up transmission is to reduce the
> amount of stuff you are transmitting. If you are going to transmit
> a jpeg of your favorite what-ever, it's already compressed, so the _data_
> can't be reduced any further. That leaves the headers - 40 bytes minimum
> (64 max) for IP and the same for TCP. And you must remember than any
> scheme you come up with to reduce the headers size is ONLY going to work
> between endpoints you control - because the rest of the world won't know
> what your shortened packet is (and will therefore discard it).

JPEG compression is not very good. You can gzip them and get
significant savings. They're only compressed in relation to a pure
bitmap or something like a TIFF. Chances are, almost any data being
transmitted could be compressed with good results.

The point you're making here about losing header space is perfectly
valid though. IMHO, there's not much you're going to do if you want a
universally acceptable packet.

On 27 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, Ken Roberts wrote:

>Moe Trin wrote:

>> It also has virtually nothing to do with Linux, but I see you already
>> multiposted the same question to comp.protocols.tcp-ip.
>
>Why does it always need to take this tone?

Ken, it's a pain when you spend a few minutes working up a reply to a post
only to find it in one (or more) other news groups you read. If this is
the only group you read, that may be fine for you, but I have to scan 90
different groups (though only about half that are over 10 articles a day)
trying to stay on top of things.

>What you're describing is still IP traffic in every sense that matters.
>Whatever protocol is nested inside is just data, and the other end
>will either know what to do with it or not.

It's IP all right, but it's not the TCP/IP that you and the O/P were
talking about.

>Tunnelling an additional protocol inside your packet is NOT a way to
>reduce overhead. GPRS uses IP as a base standard, so no matter what he's
>going to have IP.

That's not really tunneling any more than carrying a common protocol like
TCP. IP by itself can't directly carry data - it only encapsulates other
protocols that may.

>JPEG compression is not very good. You can gzip them and get
>significant savings. They're only compressed in relation to a pure
>bitmap or something like a TIFF. Chances are, almost any data being
>transmitted could be compressed with good results.

I used the .jpeg as an example. The O/P didn't mention the data contents.
However, if the O/P is going to reduce the size of the packet, this is
the only reasonable place in practice. Neither header compression or
using some other protocol in place of TCP or UDP is going to offer much
in savings.

>The point you're making here about losing header space is perfectly
>valid though. IMHO, there's not much you're going to do if you want a
>universally acceptable packet.

Header compression is about the only thing you can do OTHER THAN the
compression of the data before inserting it into the packet, and it
only works on a single link. It's got to be compressed and uncompressed
at each end of the link (such as you dialing in to some ISP), because
the routers can't be expected to have any clue what was negotiated. They're
only going to handle IPv4 (and maybe IPv6). And as mentioned, VJ only
works on established connections.

Old guy

Moe Trin wrote:
> On 27 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
> <(E-Mail Removed). com>, Ken Roberts wrote:
>
> >Moe Trin wrote:
>
> >> It also has virtually nothing to do with Linux, but I see you already
> >> multiposted the same question to comp.protocols.tcp-ip.
> >
> >Why does it always need to take this tone?
>
> Ken, it's a pain when you spend a few minutes working up a reply to a post
> only to find it in one (or more) other news groups you read. If this is
> the only group you read, that may be fine for you, but I have to scan 90
> different groups (though only about half that are over 10 articles a day)
> trying to stay on top of things.

How about saying, "please don't cross post" and include a link like
http://www.webhero.org/Newsgroups/crossposting.htm

> >What you're describing is still IP traffic in every sense that matters.
> >Whatever protocol is nested inside is just data, and the other end
> >will either know what to do with it or not.
>
> It's IP all right, but it's not the TCP/IP that you and the O/P were
> talking about.

I don't know what you thought I was talking about, but as you say below
EVERY ip packet is simply an envelope for some other format or
protocol. So it is exactly what I was talking about.

> >Tunnelling an additional protocol inside your packet is NOT a way to
> >reduce overhead. GPRS uses IP as a base standard, so no matter what he's
> >going to have IP.
>
> That's not really tunneling any more than carrying a common protocol like
> TCP. IP by itself can't directly carry data - it only encapsulates other
> protocols that may.

http://computing-dictionary.thefreed...Network+tunnel

Something like appletalk IS tunneling, which is one of the things you
were talking about. Transporting a protocol of the same or lower layer
than the protocol used as transport, is a tunnel by definition. At
least back when I learned about it, appletalk went right on top of the
ethernet packets or right over the serial lines in the case of the
phone net stuff. It has/had the ability to locate a single host on a
network of networks. That makes it equivalent to IP in layers, and the
other protocols you're describing are all similar as far as I know,
although I have never dealt with any of the others.

> >JPEG compression is not very good. You can gzip them and get
> >significant savings. They're only compressed in relation to a pure
> >bitmap or something like a TIFF. Chances are, almost any data being
> >transmitted could be compressed with good results.
>
> I used the .jpeg as an example. The O/P didn't mention the data contents.
> However, if the O/P is going to reduce the size of the packet, this is
> the only reasonable place in practice. Neither header compression or
> using some other protocol in place of TCP or UDP is going to offer much
> in savings.

Compressing the data being transferred is likely to give better results
than header compression, or than tinkering with the header at all.
Moreover, it can be done invisibly so that everything that goes through
your interface is compressed. With GPRS it might actually be doing
that for all I know.

> >The point you're making here about losing header space is perfectly
> >valid though. IMHO, there's not much you're going to do if you want a
> >universally acceptable packet.
>
> Header compression is about the only thing you can do OTHER THAN the
> compression of the data before inserting it into the packet, and it
> only works on a single link. It's got to be compressed and uncompressed
> at each end of the link (such as you dialing in to some ISP), because
> the routers can't be expected to have any clue what was negotiated. They're
> only going to handle IPv4 (and maybe IPv6). And as mentioned, VJ only
> works on established connections.

Agreed.

Drifting...

Some boilerplate I trot-out from time to time that may be helpful:

One can specify more than one newsgroup in the Newsgroups: line. The
format would look like this:

Newsgroups: group1,group2,group3

with no spaces in the grouplist. This has several advantages (so long
as it is not abused by posting messages to inappropriate groups). Only
one copy of your message must traverse the Internet, saving network
bandwidth; only one copy of your message must be stored on each news
server on the Internet, saving many MB of space world-wide; you only
have to enter the news posting once, saving you time; people only have
to read/skip your post once, saving them time; all responses in any
group can be seen in all groups, keeping everyone up to date with the
conversation.

Also, you can add a Followup-to: header line which will direct all the
follow-ups to a particular group, making it easier for you to look for
responses.

I hope you find this helpful. If you do, please pass it along to your
peers as you see them needing the same advice.

sincerely,

rick jones

--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...