Date: Wed, 26 Jan 94 04:30:05 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V94 #22
To: tcp-group-digest
TCP-Group Digest Wed, 26 Jan 94 Volume 94 : Issue 22
Today's Topics:
Ethernet ID's
Ethernet protocol ID (3 msgs)
GPIB and packet (2 msgs)
help understanding the division point of protocol vs app
JNOS, TNOS, and other DOS'isms (4 msgs)
JNOS problems...
limiting socket connections
TCP MSS and TCP WIN settings (5 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Wed, 26 Jan 94 09:30:54 GMT
From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
Subject: Ethernet ID's
To: tcp-group@ucsd.edu
One is posted to usenet occasionally. There are two problems howver. Firstly
I can't find my old copy or remember the group, secondly some of it is guesswork
because Xerox don't reveal who owns what ID or what for.
Alan
------------------------------
Date: Tue, 25 Jan 1994 13:04:42 -0600 (CST)
From: drk@fed-ins.ca (Dan Keizer)
Subject: Ethernet protocol ID
To: tcp-group@ucsd.edu
Does anyone know where I can find a concise (or as consise as possible)
listing of known ethernet protocol id's?? I know in the ethernetdump
routing in NOS it identifies 3 of them and then just displays the protocols'
number otherwise. I checked the RFC's but nothing stood out as describing
the #'s, even though I did look through quite a few. (what a maze)
Dan.
------------------------------------------------------------------------
Dan Keizer, VE4DRK Federated Insurance Company of Canada
drk@fed-ins.ca 717 Portage Ave, Winnipeg, MB R3C 3C9
Opinions are mine and that's that. TEL:(204) 786-6431 FAX:(204) 786-5707
------------------------------
Date: Tue, 25 Jan 1994 21:11:13 +0000 (GMT)
From: jerry@tr2.com
Subject: Ethernet protocol ID
To: drk@fed-ins.ca (Dan Keizer)
>
> Does anyone know where I can find a concise (or as consise as possible)
> listing of known ethernet protocol id's?? I know in the ethernetdump
> routing in NOS it identifies 3 of them and then just displays the protocols'
> number otherwise. I checked the RFC's but nothing stood out as describing
> the #'s, even though I did look through quite a few. (what a maze)
**** FTP Software has this fantastic poster that splits ethernet packets
up into protocol layers and lists all or many of the fields in each layer.
They usually give it out at trade shows, and if you called them and asked
nicely, they just might send you one.
I don't think you'll find enet packet types in an RFC; ethernet is not
really an IP protocol.
- Jerry, KF6VB
p.s. You think the RFCs are a morass? You should try token ring some
time. Now, THAT's a morass!
***************************************************************
* Jerry Kaidor jerry@tr2.com, jkaidor@synoptics.com *
* jerry@KF6VB.ampr.org *
***************************************************************
------------------------------
Date: Wed, 26 Jan 94 01:44:00 -0000
From: mikebw@bilow.uu.ids.net (Mike Bilow)
Subject: Ethernet protocol ID
To: tcp-group@ucsd.edu
Cc: drk@fed-ins.ca
In a msg on <Jan 25 19:04>, Dan Keizer writes:
DK> Does anyone know where I can find a concise (or as consise as
DK> possible) listing of known ethernet protocol id's?? I know
DK> in the ethernetdump routing in NOS it identifies 3 of them
DK> and then just displays the protocols' number otherwise. I
DK> checked the RFC's but nothing stood out as describing the
DK> #'s, even though I did look through quite a few. (what a
DK> maze)
There is a pretty good listing in the ETHLD???.ZIP package available from
ub4b.buug.be in /pub/ub4b/network/msdos. This is a public domain Ethernet
protocol analyzer.
For those unable to access it by Internet FTP, I have it available for
dial-up download at the N1BEE BBS, +1 401 944 8498, as ETHLD103.ZIP.
The file is about 140 KB.
-- Mike
------------------------------
Date: Tue, 25 Jan 94 13:03:33 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: GPIB and packet
To: TCP-Group@UCSD.EDU, jas@hplb.hpl.hp.com
FYI -
The Circuit Cellar BBS has a parallel to GPIB adapter info and SW
GPIBLPT.ZIP
Doug
------------------------------
Date: Wed, 26 Jan 1994 09:28:19 EET-2EEST
From: "Markus Lamminmaki OH6LSA" <MARKUS@TECHNIS.vtyh.fi>
Subject: GPIB and packet
To: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
>FYI -
>
>The Circuit Cellar BBS has a parallel to GPIB adapter info and SW
>
>GPIBLPT.ZIP
I tried to look for it with archie but could not find any references.
Could you put it somewhere where I could ftp this file from.
---
Vasa Polytechnic Email: markus@technis.vtyh.fi
PB 6, SF-65201, FINLAND postmaster@vtyh.fi
Fax: +358-61-3230 610
Work:+358-61-3230 661 Home: +358-61-3171 466
Looks great on the outside, but Intel inside.
------------------------------
Date: Tue, 25 Jan 1994 22:40:11 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: help understanding the division point of protocol vs app
To: mikebw@bilow.uu.ids.net
Ah yes, the layering wars...takes me way back...
A few random tidbits:
Postel and Cohen published a paper a while back that shows that if the
ISO 7-layer model is correct, then n = n+1. (This is known as a
disproof by contradiction). The problem, btw, comes when you stack up
things in an ad-hoc fashion, as so often happens in the real world
both because it's often necessary and because the Internet protocols
make it so easy to do. For example, it would be entirely possible to
encode IP inside email messages and build a (slow) "super internet"
out of it. Then which layer do your mail-encoded IP headers belong to?
Okay, so this might be crazy. But what about the idea of encoding SLIP
or PPP packets as lines of ASCII characters and sending them over a
Telnet connection to a server out on the net that unwraps them and
puts them back out on the net? (I've been threatening to do exactly
this in NOS for some time to give people a way to get logical IP
connectivity to the Internet through public-access UNIX sites on the
Internet that either don't provide SLIP/PPP service, or charge
ridiculous prices for it.)
What matters is the order in which you stack the protocols, not what
"ISO layer name/number" you should assign to each one.
Perhaps the best philosphy I've heard is "layering makes a good
servant, but a bad master". Who said this? Dave Clark?
Phil
------------------------------
Date: Mon, 24 Jan 94 22:50:07 PST
From: algedi!gateway (gateway)
Subject: JNOS, TNOS, and other DOS'isms
To: tcp-group@ucsd.edu
In your message of Fri, 21 Jan 1994 20:56:00 GMT, you write:
+---------------
|people were not arguing over it. No one knows what the future is going to look
|like, but I personally hope it looks a lot more like Unix or OS/2 than Windows.
| My own view is that it is up to the people who write the source code.
+------------->8
Only in part; but as always, the final decision is up to the people who *use*
the code. There are several choices for Unix "NOS" (in quotes because I
include kernel-based solutions that don't involve dedticated NOS executables)
already; OS/2 NOS development seems to be lagging, and I'm not sure what there
is (native) for MS-Windows, if anything; but, should those environments have
NOS versions available, which one will be "the" future NOS environment will
depend on how many people choose which environments.
(Nor is this specific to NOS. The same considerations apply to the choice of
environment for any other application, whether it be amateur radio networking
or databases.)
What the developers do is enable that decision to be made; they don't make the
decision for you.
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development." ---dmeggins@aix1.uottawa.ca
------------------------------
Date: Mon, 24 Jan 94 23:50:04 PST
From: algedi!gateway (gateway)
Subject: JNOS, TNOS, and other DOS'isms
To: tcp-group@ucsd.edu
>It would be fairly easy to generate a special header file for older Borland
>compilers that would implement some extremely simple text translations, such
>as defining the newer prefaces (like "_dos_") so that they were stripped by
>translating them to empty text strings.
I took an easier route. I got rid of the DOS on top of DOS code! I don't see
any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff)
and I just deleted all that bo-jive. Which brings me to my political comment
of the month. One thing I *really* don't like about JNOS and TNOS is their
attempt at loading all these MS-DOS features into the code. Get rid of that
CRAP and get back on track. The other thing is the BBS code. I'd throw away
all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a
nice news feed. Your local community would probably appreciate the breath of
fresh air from the obsolete BBS interface, addressing, and forwarding methods.
By the way I use DesqView and a simple ALT-ALT tap gets me a nice window that
does all that CRAP that is flowing into NOS. Windows could do the same, but
it needs a lot more memory I suspect.
Those were very useful comments though, about the BC limitations and changes
Mike, thanks.
---
Steve N5OWK@W1AW.#LEFT.#RIGHT.#LEFT.#UP.#DOWN.#AROUND.CT.USA.NA.EARTH.ZF101
"My views are official and represent the governments feeling on the subject"
------------------------------
Date: Tue, 25 Jan 94 01:50:04 PST
From: algedi!gateway (gateway)
Subject: JNOS, TNOS, and other DOS'isms
To: ssampson@sabea-oc.af.mil, tcp-group@ucsd.edu
> I took an easier route. I got rid of the DOS on top of DOS code! I don't see
> any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff)
> and I just deleted all that bo-jive. Which brings me to my political comment
The reason for having those in the code is so you don't have to shell out
(and worry you still have enough core left) when you want to do that
dir, more, delete, or rename). If you don't need these, the ifdef the
commands out (that's what config.h is for).
> ... The other thing is the BBS code. I'd throw away
> all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a
> nice news feed. Your local community would probably appreciate the breath of
> fresh air from the obsolete BBS interface, addressing, and forwarding methods.
Those of us on the local frequency would probably agree. Why don't you
write a version for us that has a decent nntp and full smtp support
(for those of us who don't have >1M of memory and can't multitask :).
Don't forget to include a sysop shell for remote node support (yes, we
use sysop here to remotely control stations, such as the router).
Ohh yea... converse is one of the most popular IP modes around here,
although we could use a multicast protocol :).
[I guess this called "put you code where your mouth is :) ]
[Not to say I am not working on any of this, just that I have to complete
some other projects before I can work on my release of nos ... ]
milton
--
Milton Miller KB5TKF miltonm@austin.ibm.com
I never speak for IBM.
------------------------------
Date: Tue, 25 Jan 1994 15:47:50 -0600 (CST)
From: ssampson@sabea-oc.af.mil (Steve Sampson)
Subject: JNOS, TNOS, and other DOS'isms
To: algedi!gateway (gateway)
>
>
> > I took an easier route. I got rid of the DOS on top of DOS code! I don't see
> > any reason for DIR RENAME and COPY inside NOS (as well as a lot of other fluff)
> > and I just deleted all that bo-jive. Which brings me to my political comment
>
> The reason for having those in the code is so you don't have to shell out
> (and worry you still have enough core left) when you want to do that
> dir, more, delete, or rename). If you don't need these, the ifdef the
> commands out (that's what config.h is for).
>
> > ... The other thing is the BBS code. I'd throw away
> > all that mailbox CRAP, it's obsolete. Why not expand on the NNTP and make a
> > nice news feed. Your local community would probably appreciate the breath of
> > fresh air from the obsolete BBS interface, addressing, and forwarding methods.
>
> Those of us on the local frequency would probably agree. Why don't you
> write a version for us that has a decent nntp and full smtp support
> (for those of us who don't have >1M of memory and can't multitask :).
> Don't forget to include a sysop shell for remote node support (yes, we
> use sysop here to remotely control stations, such as the router).
> Ohh yea... converse is one of the most popular IP modes around here,
> although we could use a multicast protocol :).
>
> [I guess this called "put you code where your mouth is :) ]
>
> [Not to say I am not working on any of this, just that I have to complete
> some other projects before I can work on my release of nos ... ]
>
> milton
> --
> Milton Miller KB5TKF miltonm@austin.ibm.com
> I never speak for IBM.
>
>
>
Why am I getting mail from this machine?? It's echoing everything with
a two day delay or more...
--
Steve
------------------------------
Date: Mon, 24 Jan 1994 22:54 +0200
From: "Miroslav Skoric, SysOp in YU7B, Novi Sad" <etfbg!SKORIC%UNSIM>
Subject: JNOS problems...
To: fon!tcp-group@ucsd.edu
Hello there...
I've installed JNOSv1.10x9 and have configured it only as "normal" packet
ax.25 station. Unfortunately, I really don't know how to make it full tcp/ip
packet/internet bbs (or) gateway, which was the main reason for supplying
such software.
I've been running ax.25 packet bbs YU7B.SRB.YUG.EU with telephone modem access
possibility and I have user access to the local Internet/VAX system via phone
modem. I want to run this JNOS as full packet-internet bbs.
I've made dialer, forward.bbs and the other files, but I am not able to
connect anyone via phone modem now, especialy not automaticaly as, for example
FBB software does.
If somebody could help me to establish the FIRST tcpip bbs in YU* land, don't
hesitate to contact me, either via Internet or packet radio. If using Internet
pse don't press REPLY now, but instead type the whole address:
skoric%unsim%etfbg%fon.uucp@moumee.calstatela.edu
or via packet: YT7MPB@YU7B.SRB.YUG.EU
Best wishes and 73 from Misko, YT7MPB
------------------------------
Date: Tue, 25 Jan 94 11:04:18 PST
From: Glenn Engel <glenne@lsid.hp.com>
Subject: limiting socket connections
To: tcp-group@ucsd.edu
I've seen a number of references to people having problems with sockets
hanging around "forever". The following patch is one I've used to help
with this problem. When a new connection is initiated, a check is made to
see if the current number of connections is greater than the tcpMaxConn
limit. If the limit is exceeded, the connection which has been idle
for the longest period of time will be closed. By setting the tcpMaxConn
value large enough to cover "active" connections, this effectively causes
old connections to die a graceful death.
No copyright implied or assumed for this software. Use it however you wish.
--
Glenn
*** /usr/tmp/fdif1AAAa12357 Tue Jan 25 13:56:25 1994
--- tcpin.c Mon Jan 24 12:01:41 1994
***************
*** 23,28 ****
--- 23,59 ----
uint16 *length);
static int in_window(struct tcb *tcb,int32 seq);
+ /**********************************************************************/
+ /* This function attempts to limit the number of tcp connections. It */
+ /* walks thru the list of tcbs and counts all connections which are */
+ /* not in the CLOSED or LISTEN state. If this count is greater than */
+ /* the limit then the tcb which was used last is removed. Because */
+ /* lookup_tcb puts found items at the head, we know that the tail of */
+ /* the list is the tcb which has the greatest time since last used. */
+ /**********************************************************************/
+ void checkNumTcbLimit(void)
+ {
+ struct tcb *tcb;
+ struct tcb *tcblast;
+ int numTcb = 0;
+
+ for(tcb=Tcbs;tcb != NULLTCB;tcb = tcb->next)
+ {
+ if ((tcb->state > TCP_LISTEN) && (tcb->state < TCP_FINWAIT1))
+ {
+ numTcb++;
+ tcblast = tcb;
+ }
+ }
+
+ if (numTcb >= tcpMaxConn)
+ {
+ /* drop the oldest tcb */
+ close_tcp(tcblast);
+ }
+ }
+
+
/* This function is called from IP with the IP header in machine byte order,
* along with a mbuf chain pointing to the TCP header.
*/
***************
*** 133,138 ****
--- 164,171 ----
return;
}
if(seg.flags.syn){
+ /* check for too many tcbs */
+ checkNumTcbLimit();
/* (Security check is bypassed) */
/* page 66 */
proc_syn(tcb,ip->tos,&seg);
------------------------------
Date: Mon, 24 Jan 1994 23:11:02 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: TCP MSS and TCP WIN settings
To: CHRISC@Central.nmmc.mn.org
>I don't see how you could tell. The determination of how a packet is
>routed is under the auspices of IP not TCP. It is quite conceivable,
>even on a radio circuit, that a packet (or rather stream of
>characters) which is queued, but not acknowledged, could be resent by
>a completely different path on each attempt at transmission.
You are quite correct; the trick of asking the IP layer for the MTU of
the interface that is currently used to reach the remote site *is* a
layering violation, and as you say the interface can change
anyway. But it does so only rarely in practice, so it's a useful
violation.
These issues are actually longstanding problems with TCP/IP. The first
one, determining the largest MSS that will avoid fragmentation, now
has a proper solution - MTU path discovery. The sender sets the "DF"
(don't fragment) flag in every IP header. If the packet hits a gateway
with an interface that requires fragmentation, the packet is bounced
with an ICMP "Unreachable - fragmentation required and DF set"
message. If the ICMP message includes the interface MTU so the sender
can know how much smaller to make the packet -- unless, of course,
there's another router down the line with an even smaller MTU.
The trick is that the ICMP message didn't include the interface MTU
until the MTU path discovery feature was adopted. If the "bottleneck"
router doesn't support it, then the sender has to guess at a packet
size that will fit - simply halving the packet size until it gets
through will probably work.
I put in the ICMP MTU reporting feature some time ago, but I haven't
done the needed work in TCP to actually invoke it yet. I figured that
I should let the ICMP update percolate around first (that is, if
anybody's tracking my code anymore). Perhaps it's time to finish the
job.
The other problem, that of controlling the TCP window size, is much
more problematical.
What you really want to control is *not* the window size that the
receiver advertises - this simply indicates how much memory it has
available for buffering - but the effective, or "congestion" window
that the sender uses. Van Jacobsen made a tremendous advance in this
area some years back by introducing the congestion window concept and
the "slow start" and "congestion recovery" algorithms that adjust
it. My TCP was one of the first (after Van's) to implement it, because
amateur packet radio channels are as congested as any that support
TCP.
But Van didn't solve the whole problem, because the only way to keep
the congestion window from eventually increasing all the way to the
window advertised by the receiver is to drop a packet, and this is
wasteful. And it's possible for several TCPs all running slowstart to
get locked into a relaxation cycle: they all increase their congestion
windows together until the network starts dropping their packets, then
they back off again and start the process all over.
One elegant solution is the "DEC Bit" scheme proposed by DEC for ISO
CLNP. When a router experiences congestion on a link, it sets a "congestion
experienced" bit in the header. The receiver echoes this bit back to the
sender in its transport ACK header, and the sender modulates his congestion
window appropriately. The idea is to keep the bottleneck link along the path
just saturated, without piling up a long queue behind it.
I've wanted to put this into TCP/IP for some time (can't stand the
notion of there being a useful feature in ISO that's not in TCP/IP!)
but it requires the cooperation of a lot of vendors to make this
happen. So I've long been interested in backward-compatible schemes
to accomplish the same thing. I haven't found any that really work, but
that's probably because I don't know enough control theory.
So just to do something to keep queues reasonable, I stuck in a
"qlimit" feature. Whenever an interface transmit queue exceeds the
queue limit, the routing code picks a packet at random from the queue
and sends a source quench to its sender (without dropping the
packet). This could be called a "random quench" policy. The TCP that
gets the quench will shrink its congestion window to 1 packet, just as
if it had encountered a timeout. The congestion window will still
oscillate, but it definitely does keep the queues shorter.
Van Jacobsen and Sally Floyd did recently publish a paper in ACM/IEEE
Networks magazine on some much more clever congestion avoidance
algorithms for gateways. I have a copy and will implement it when I
get a chance.
In the meantime, if somebody can come up with a simple, reliable and
stable algorithm for setting the TCP congestion window to the right
value just by observing changes in round trip delays and bandwidths,
you could make yourself famous.
Phil
------------------------------
Date: Tue, 25 Jan 1994 09:20:13 -0500
From: goldstein@carafe.tay2.dec.com
Subject: TCP MSS and TCP WIN settings
To: tcp-group@ucsd.edu
Phil,
Several years ago, Raj Jain and K.K Ramakrishnan (I think it was the two
of them as a team) published a paper describing a congestion avoidance
scheme based on round-trip delay observation. I haven't looked at it for
a while but my recollection is that they weren't impressed by the
results, so they didn't pursue it farther. (Note to net_readers:
Jain actually invented the scheme that Van Jacobsen is widely credited
for; it was done for DECnet Phase IV in 1984 and Jacobsen acknowledges
it in his own paper. Jacobsen made a minor improvement of his own.)
Folks at Digital have been trying for years to get the IETF to put a
DECbit into IP, but it keeps running into two political problems. One,
it was invented elsewhere, and is tainted by the OSI label (since they
took Digital's suggestion). Two, it is hard to phase in: If you put DECbit congestion avoidance into your TCP and I don't put it in
mine, you'll slow down (nice fella!) and I won't, and I'll be taking
advantage of the bandwidth you freed up. It's a "nice guys finish
last" scenario. WIth all of the J-random implementations of TCP
floating around, this might be a real issue for a while, though there
are of course workarounds. ("MANDATORY" worked for V.J.)
Frame Relay (T1.618/Q.922) has a FECN bit which is there explicitly
to support this "DECbit" concept. If we can't get it into IP, maybe
it should go into IPNG, whatever that turns out to be.
fred k1io
------------------------------
Date: Tue, 25 Jan 94 14:56:00 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: TCP MSS and TCP WIN settings
To: tcp-group@ucsd.edu (TCP Group)
Phil wrote:
> [...]
> I put in the ICMP MTU reporting feature some time ago, but I haven't
> done the needed work in TCP to actually invoke it yet. I figured that
> I should let the ICMP update percolate around first (that is, if
> anybody's tracking my code anymore). Perhaps it's time to finish the
> job.
> [...]
I can vouch for the MTU reporting abilities of most recent
versions of NOS, a while back I tried to hack MTU discovery
into SunOS 4.1.2 - but for some reason (on the sun) it didn't
seem to work too well. Locally, we came up with a far more
draconian fix (MSS & window snooping - NOS actually alters
the packets as they pass through). Before I get long, angry
flames from the four corners of the world, this was to fix
the specific problems of *nix boxes on local ethernets
which had the misfortune of being linked by AX.25. It
has been working well for over a year now.
I'm putting a SunOS 4.1.3 machine up soon, maybe I'll revisit
path MTU discovery....
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Tue, 25 Jan 1994 13:13:50 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: TCP MSS and TCP WIN settings
To: goldstein@carafe.enet.dec.com
Fred,
Now that you mention it, I do remember that Raj invented what Van
called "slow start". I *think* Van said he reinvented it
independently. In any event, Raj picked the wrong protocol stack to
implement it in, so Van gets all the credit. :-)
I really don't think NIH explains why the DECbit scheme didn't get
into IP. Nor is there a "nice guys finish last" problem. If anything,
there should have been one with slow start, but it got deployed pretty
quickly anyway.
I think there are three problems: one, there was a widespread perception
that there must exist a way to control gateway congestion without
having to modify IP and every router that handles it. Two, the
NSFNet backbone bandwidth has increased almost 1,000x over what it was
back when TCP congestion control algorithms were such a hot topic.
Despite the enormous growth of the net this has pretty much eliminated
the widespread backbone congestion that used to occur back then, so
there is now much less interest in this problem. Three, both TCPs
in a connection have to be aware of the scheme, because the sending
TCP relies on the other TCP to "reflect back" the IP congestion
experienced bit in its own header.
Van has contributed greatly to the first problem. I remember some
really strong arguments at IETF meetings between him and Raj and KK
about whether the DECbit scheme was really needed, or whether you
could do everything with packet drops and throughput/delay
measurements. By the time everybody sort of came to the conclusion
that Raj and KK were right, the problem had sort of lost its appeal.
I still think it's not too late to install the Decbit scheme in IP.
There's a spare bit in the flags field (right next to the MF and DF
bits) that could be used. I've had code in my own IP and TCP for some
time that reflects this bit back in another spare bit in the TCP
header, in preparation for eventually implementing the scheme. Again,
I wanted to make sure that there would be enough compatible systems
out there to make this thing work. But I haven't taken it beyond that.
Maybe it's time to try it, at least experimentally, and then write up
an Internet Draft. One remaining concern: how many broken hosts and
gateways either refuse to pass this (currently unused) IP header bit,
or worse, will break when it is set?
Phil
------------------------------
Date: Wed, 26 Jan 94 09:50:28 GMT
From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
Subject: TCP MSS and TCP WIN settings
To: CHRISC@Central.nmmc.mn.org, karn@qualcomm.com
This of course raises the other peril of MTU discovery - packets which go
off on different routes. The single MTU is all very well until one stray packet
goes via a low mtu link due to congestion - now everything you send suffers.
Alan
------------------------------
Date: Mon, 24 Jan 94 20:50:06 PST
From: algedi!gateway (gateway)
To: tcp-group@ucsd.edu
help
--
Eric T. Budinger Dan's Domain 201-586-1223
budinger@ds.gen.nj.us Ham Central SysOp
ericbud@ritz.mordor.com 1-201-398-4619 (voice)
n2koj@w2xo.pa.usa.na 1-201-205-2134 (digital)
------------------------------
End of TCP-Group Digest V94 #22
******************************
******************************