murayama@CS.UCL.AC.UK (Yuko Murayama) (09/07/87)
Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London
tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) (09/08/87)
The simple reply is that they are very similar functionally, but different in terms of header format and all that. I would be hard pressed to say what the important differences were since that depends on ones priorities. However, the ISO8473 address is much bigger (up to 20 bytes vs. 4 for DoD IP). I like the partial source routing of ISO8473 because I am involved in routing. However, that feature can bite you if you are not careful, and I wouldn't be surprized if it never gets widely implemented. If one consideres ICMP to part and parcel of DoD IP, then there are a couple more differences. ICMP has the Echo function, which ISO8473 does not, and has the Redirect. However, ISO9542 (the ES-IS routing protocol for use with ISO8473) has the redirect function, so its tit for tat. I will be interested to see what others perceive as the major differences between the two. I have never sat down and made a blow by blow comparison. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
bhanji@GATEWAY.MITRE.ORG (09/08/87)
Date: Mon, 7 Sep 87 12:21:51 GMT-0:00 From: Yuko Murayama <murayama@Cs.Ucl.AC.UK> Could anyone let me know about the difference between ISO 8473 (protocol for providing the connectionless-mode network service) and the DARPA IP? Yuko Murayama a Ph.D. student Dept of Computer Science University College London A document put out by the National Research Council in 1985 briefly describes the differences between the DoD IP and ISO IP pp 18-24. The report is mostly dedicated to the comparison between TCP and TP4 but has a small section on the two IP comparison. "Transport Protocols for Department of Defense Data Networks", Report to the Department of Defense and the Bureau of Standards. Committee on Computer-Computer Communication Protocols, Board on Telecommunications and Computer Applications, Commission on Engineering and Technical Systems, National Research Council. NATIONAL ACADEMY PRESS, Washington, D.C. February 1985. Hope this is helpful. Shiraz Bhanji.
hagens@JANEB.WISC.EDU (Robert Hagens) (09/08/87)
Comparison of DoD IP and ISO IP: As Paul pointed out, functionally the same. Here are some other differences: - No upper layer protocol ID in ISO8473. - Headers in ISO8473 can be 255 octets (vs. 60 for DoD IP). - Support of header parameters is optional in ISO8473, mandatory in DoD IP. - Time to live in ISO8473 is 1/2 sec as opposed to 1 sec for DoD IP. (It will still end up being used as a hop count.) - No timestamp parameter in ISO8473. - Fixed part of ISO8473 header has odd byte aligned, 2 byte fields. - DoD IP fragmentation is called segmentation in ISO. Identical function, however all ISO8473 optional parameters are carried with fragment. (Called a derived PDU). Only in ISO8473: - Error Report PDU. Sent when a data PDU is discarded. Almost identical to data pdu except it contains the reason for discard. Data of error report PDU is header of discarded PDU. Error report contains ICMP functionality of destination unreachable, ttl expired and parameter problem. - 'congestion experienced'. Set by a router, when a router experiences congestion. The two biggest differences I see are the address part and lack of upper layer proto id. Rob Hagens UW Madison Computer Science
tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) (09/08/87)
> > Comparison of DoD IP and ISO IP: > > As Paul pointed out, functionally the same. Here are some other differences: > > - No upper layer protocol ID in ISO8473................... > > The two biggest differences I see are the address part and lack of > upper layer proto id. > > Rob Hagens > UW Madison Computer Science > This is not to say that ISO8473 cannot distinguish between upper layer protocols. The address in ISO8473 is used to do the distinguishing (the address is called the Network Service Access Point Address, which defines the boundary between the transport thing and the network thing. I don't want to get into what "thing" is). Practically speaking, one reserves a byte (sorry, octet) in the NSAP address, usually called the NSAP selector, to do the job of the protocol id field in DoD IP. Boils down to the same thing as far as I can tell. (I'm wondering if it is kosher to use the NSAP selector byte to distinguish between different transport classes (TP0, TP1, ...., TP4). Something tells me it isn't, but I don't see how someone could stop you. I'll have to bring that up at the next 3.3 meeting). Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) (09/08/87)
> From: "Marty Schoffstall" <schoff@nic.nyser.net> > Status: R > > > - 'congestion experienced'. Set by a router, when a router > experiences congestion. > > The infamous "DEC Bit", which reports to the recipient of the packet > that there is congestion. This bit has debatable merit, would the > two camps like to expound? > > Marty Ok, I'll bite. The DEC bit is used, at least in DECNET (phase 4 or 5, I don't know) to control the transport window such that the network doesn't get congested. It is a "congestion avoidance" mechanism. As far as I know, the algorithm assumes it knows the round trip time. I don't know if DEC measures this or assumes a value. (I understand the problems associated with trying to measure it.) The algorithm seems to be a good one, and works as long as all of the parts are there and everyone participates. (Please, someone from DEC correct me if I have this screwed up). DEC has released there algorithm for doing this (until recently, it was proprietary). In their IS-IS routing proposal, they have said when to set the bit. I am not sure how or if they intend to standardize the part that tells the transport machine what to do. I suppose this could be done right in ISO, or in one of the profile organizations like COS. Tsuchiya PS. We may be in two camps, but lets face it: if it rains, all of our campfires are going to go out.
schoff@NIC.NYSER.NET ("Marty Schoffstall") (09/08/87)
- 'congestion experienced'. Set by a router, when a router
experiences congestion.
The infamous "DEC Bit", which reports to the recipient of the packet
that there is congestion. This bit has debatable merit, would the
two camps like to expound?
Martycarrs@TROUT.NOSC.MIL (Stephen M. Carr) (09/09/87)
-------
Ref: (a) National Research Council, "Transport Protocols for
Department of Defense Data Networks", RFC942, National
Academy Press, Washington, D.C., February 1985
Yuko,
1. Reference (a) document which Shiraz Bhanji referred to is
online at sri-nic.arpa. The path name is <RFC>RFC942.TXT. So if
you have FTP capability, you can download it. It is in excess of
217,000 bytes.
2. I am assuming that you don't have FTP capability from your
host into the ARPANET/MILNET. Therefore, if you would like, I or
one of your colleagues could try to forward it to you via SMTP.
3. Here is a list of other recent RFCs which might interest you
on related subjects. All of these documents are online in the
same directory.
RFC INDEX
(RFC1008)
Jun 87 (McCoy) Implementation Guide for the ISO
Transport Protocol
(RFC1007) Jun 87 (McCoy) Military Supplement to the ISO
Transport Protocol
(RFC1006)
May 87 (Rose) ISO Transport Services on top
of the TCP Version:3 (Obsoletes RFC 983)
(RFC995)
Jan 87 (ANSIx353.3) End System to Intermediate System
Routing Exchange Protocol for use in conjunction with ISO 8473
(RFC994)
Jan 87 (ANSIx353.3) Final Text of DIS 8473, Protocol
for Providing the Connectionless Mode Network Service (Obsoletes RFC 926)
(RFC962)
... Nov 85 (Padlipsky) TCP-4 Prime
(RFC945)
... Apr 85 (Postel) DOD Statement on NRC Report
(RFC942)
... Mar 85 (NRC) Transport Protocols for Department
of Defense Data Networks
(RFC939)
... Feb 85 (NRC) Executive Summary of the NRC Report
on Transport Protocols for Department of Defense Data Networks
(RFC905)
... Apr 84 (ISO) ISO Transport Protocol Specification
(ISO DP 8073) (Obsoletes RFC 892)
4. I hope this is of some help.
Steve Carr
LCDR, SC, USN
Navy Management Systems Support Office (Code 33C)
Naval Air Station
Norfolk, Virginia 23511-6694
DDN: carrs@trout.nosc.mil
DDN: navmasso30tc@nardacva.arpa
-------Mills@UDEL.EDU (09/09/87)
Marty, The "congestion experienced" bit has to be a good idea, since it has been suggested repeatedly by Jack Haverty (name one) and several others at BBN for darn near ten years. So, let's do it. We need to swipe a bit from the IP header. Any suggestions on which one? That bit decided, give me ten seconds and the fuzzballs will concur in the madness... Dave
CERF@A.ISI.EDU (09/09/87)
RE: DEC Bit (Congestion Experienced) When I talked with Tony Lauck about this notion, the idea was that you could tell the receiving party "sooner" than the sending party about this congestion problem and that the receiving party might use the window mechanism to reduce the sender's ambition level until the congestion had died away. The sender probably needs to know about the congestion explicitly, too, if there is any option for re-routing the traffic from the origin via an alternate path which is less congested. It would be helpful to hear from Digital about their experiences with the dynamics of their DECNET with and without the use of this signal. Vint
schoff@NIC.NYSER.NET ("Marty Schoffstall") (09/09/87)
The "congestion experienced" bit has to be a good idea, since it has been
suggested repeatedly by Jack Haverty (name one) and several others at BBN
for darn near ten years. So, let's do it. We need to swipe a bit from the
IP header. Any suggestions on which one? That bit decided, give me ten
seconds and the fuzzballs will concur in the madness...
Dave, I don't know how to take the above message. I don't believe I have
a fully-formed opinion on this due to the fact that I have
not seen the DEC "paper" however
I have some philosophical questions about this in the ISO stack:
Isn't this mechanism a bit indirect? Does anyone have some
thoughts about latency in a live ISO INTERNET?.
Your transmitter is hosing the net, Mr. Gateway
(whoops IS), 4 PDN's away determines there is
congestion toggles the bit and we arrive at
the receiver. The receiver then takes this
Layer3 information exports it to the Layer4
machine who does something bright with it
like communicating with the transmitter Layer4.
[ My recollection of this is that Layer4 had
to be TP4, ie this wasn't going to
be effective for other transports.]
This mechanism seems right for at least experimental use in the DOD INTERNET,
a small alteration of a mature operational protocol. However, it looks
like a hack in the ISO stack if the ISO stack is supposed to have been
an improvement on what we've learned in the last 10 years....
Dave, how do you feel this should affect the TCP if implemented in the
DOD stack?
Martyschoff@NIC.NYSER.NET ("Marty Schoffstall") (09/09/87)
This paragraph isn't clear to me....
The algorithm doesn't work quite like that. In fact, the bit is
set roughly half the time, and all it takes is one packet in the
queue to set the bit. Setting it half the time has the result of getting
whose queue?
the most information out of it (information theory). So it is not
like there is a problem and then the bit is set to relieve the problem.
What is the algorithm for setting the bit then? When everything is fine?
Instead, the bit is continuously set to achieve a smooth and appropriate
flow of data into the net. I.e., we neven (hopefully) reach the point
where a transmitter is hosing the net in the first place.tsuchiya@gateway.mitre.ORG (Paul Tsuchiya) (09/09/87)
After all of this talking about the DEC scheme, I bloody well hope that DEC gives me a good job offer. I didn't want to get into details over the air. I have the breifing slides from a presentation given at the IETF in Boston last (I think it was) April. They are fairly self explanatory. Mainly, I wanted to dispel this notion that congestion control should occur when there is congestion. It should actually occur before there is congestion, and that is what the DEC algorithm does. The bit is set by gateways, and they set it whenever they have one packet in the queue. I believe this does not mean one packet per source/destination pair or anything like that, simply one packet. The bit is set in the queued packet, which means that the host receiving the set bit is not the one that sent the packet, but the one on the other end. However, that one tells the sending one to shrink its window via the normal method, and this is how the congestion information gets back to the sending host. Of course, the hosts have an algorithm they use to know how to adjust the flow. Basically, the window is increased additively and decreased multiplicatively. Also, the hosts filter by considering x number of previous bits. Again, an appeal to DEC people: please correct me if I have over-simplified, misrepresented, or in any other way screwed this up. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa
malis@CC5.BBN.COM (Andy Malis) (09/09/87)
Paul, Vint, or whoever else can help, Is there a reference available for a description of this DECNET congestion control mechanism, now that it is no longer proprietary? Thanks, Andy
Mills@UDEL.EDU (09/09/87)
Marty, My remarks should be interpreted with respect to the DARPA context, where I have some idea of what TCP and other bangers might do with it (infer source quench). Yes, is is true that the receiver, not the transmitter, sees the bit; however, our experience has been that the resources being starved are usually the buffer pool, which means the bit would probably be set on either direction at substantially the same frequency. It works either way, since either or both the transmitter or receiver can crank back the window size. I do not want to speculate on the latency of an ISO internet, except to suggest that it will probably be similar to the DARPA internet, whatever that evolves to. Dave
lekash@ORVILLE.ARPA (John Lekashman) (09/10/87)
One of the two unused bits in the type of service field. I vote for the end bit. This has something to do with the class of service experienced, rather than desired, but thats ok. Maybe the other bit can be set on ack's to indicate congestion experienced on the packet(s) this is an ack for. (After all, its got to get back to the sender somehow. reduced offered window is one way, an explicit bit's another.) john
schoff@NIC.NYSER.NET ("Marty Schoffstall") (09/10/87)
My remarks should be interpreted with respect to the DARPA context, where
I have some idea of what TCP and other bangers might do with it (infer
source quench). Yes, is is true that the receiver, not the transmitter,
sees the bit; however, our experience has been that the resources being
starved are usually the buffer pool, which means the bit would probably be
set on either direction at substantially the same frequency. It works
either way, since either or both the transmitter or receiver can crank
back the window size.
Are you then suggesting a "future DOD INTERNET gateway" should implement
this as an option and upon determining "congestion" set the bit for
the receiver and source quench the transmitter?
Still in the DOD context do you feel that a single queued datagram
should set the bit? With our gateways living on the LAN/WAN interface
and the current state of our implementations wouldn't the bit always
end up being set? (And therefore useless to us as a signpost?)
Marty
PS: To further the state of the art of Mills'isms: philosophically
if I'm in the swamp with my loaded double barrel shotgun, I'm
probably not going to call for help until I see the THIRD
alligator. DEC seems to be pushing for the sighting of
the first alligator.CERF@A.ISI.EDU (09/10/87)
What we need is a high capacity, low cost hose to hose protocol... Vint
CERF@A.ISI.EDU (09/10/87)
Andy, Tony Lauck, DEC's chief protocol architect, or John Zornig, also at DEC, could probably point you at anything not proprietary. I believe that they've entered recommendations into the ISO forum in this area so the concepts are probably quite open. I don't have John's or Tony's network mailbox IDs readily handy (oh, for a good white pages!), but perhaps someone on TCP-IP can help, or Tony or John may be reading these messages. Vint
Mills@UDEL.EDU (09/10/87)
Marty, I'm not sure a headlong leap on the DEC bit would be appropriate for the existing IP gateway munchkins, but something like this has been proposed to indicate "congestion experienced." The particular method used to determine when gateway has too much kin to munch may depend on the gateway queueing discipline, preemption policy and whether the interfaces are blocking or not, etc. If I understand the DEC bit, the bit is set on a packet that arrives for a queue with at least one packet already queued. Now, from queueing theory, we can compute for each level of traffic the probability that the queue has n customers for each n. A clever end system can then work this backwards to estimate (crudely!) the level of traffic when the bit is set. It's a nice idea and should be tried in an experiment. However, there are lots of other ideas that should be tried, too. Dave
swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) (09/10/87)
LiXia has said that she believes the DEC congestion bit approach is too simple for the real world. Is she available for comment? Scott
malis@CC5.BBN.COM (Andy Malis) (09/10/87)
Vint, Thanks much. I just got hold of "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks," by Raj Jain of DEC (IEEE J. on Selected Areas in Communications, Vol. SAC-4, no. 7, Oct. 86). It discusses many of these issues, and suggests an algorithm to adjust window sizes based upon congestion indications, although it uses retransmission timeouts to provide the congestion indication rather than a congestion bit in the packet header. Andy
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/10/87)
My initial impulse was to respond to the call for a hose to hose protocol with a private message saying "Nozzle yourself, Vinton: you really shouldn't faucet like that." Then I made the mistake of thinking a bit about what hose to hose protocols would actually be like, and I realized that there's a fairly powerful metaphor lurking there. Think about it: if you have two garden hoses, all you need is a suitably threaded (presumably "female-female") adaptor, even if the threads on each of the hoses "aren't standard". The worst that would happen is that you'd discover nobody made appropriate adaptors and it would be cheaper to buy a longer hose (which, with any luck at all, was thread compatible with the faucet) than to have someone fabricate the special widget. (Please recall I've always spoken well of physical standards, b/t/w.) But if you want to couple a fire hose and a garden hose, you'd need to call in a fluid dynamicist to calculate how long the taper had to be so as not to lead to bursting the garden hose and then go in for some serious metalwork to get the adaptor built. (Not a job for the village smithy [they shoe horses, don't they?], I'd imagine.) And if you wanted to go beyond the conventional Gateway problem, consider the Translating/Mapping Gateway analogue, where some of the time what you need is to couple a hose designed for carrying liquid oxygen with a hose designed for carrying water to your lawn: by the time you put enough heat into the adaptor so the garden hose doesn't shatter from the cold, you've probably lost sight of the fact that your lawn doesn't really need oxygen in the first place. Other permutations on the theme are doubtless available, and even relevant, but can safely be left as an exercise.... cheers, map P.S. At the risk of violating tradition and linking this back up to the question which started it all, one way of viewing the difference between ISO IP and ARPANET IP is that each is supposed to be threaded to a different faucet. But, then, another way of viewing the difference is to think about the news item I heard over the weekend, where some builder in one of the cities the Pope is visiting had donated several of his houses for the lodging of the papal entourage, since he believed they'd be worth more later because he had heard that the Pope blessed every house he entered (not clear that the Pope would enter every house, of course, but then I've never claimed to be up on ad man logic): so to change the metaphor from the lawn to the house, they do have slightly different floor plans, they both serve the same fundamental purpose of being boxes to stay out of the weather in, they're in the same neighborhood and all, but this one's gonna cost ya $25,000 more because It's Been Papally Blessed! -------
jain@erlang.DEC.COM (Raj Jain, LKG 1-2/A19 DTN: 226-7642) (09/11/87)
We have a hot-off-the-press DEC Technical Report DEC-TR-506 which
summarizes our work on congestion avoidance and explains the merits of
the 'congestion experienced' bit in ISO 8473.
Title: CONGESTION AVOIDANCE IN COMPUTER NETWORKS WITH A
CONNECTIONLESS NETWORK LAYER
Authors: Raj Jain, K. K. Ramakrishnan, Dah-Ming Chiu
Digital Equipment Corp.
Littleton, MA 01460
Date: August 1987.
If you would like a copy of the report mailed to you, please send me your
U.S. Mail address. My network address on ARPAnet is
Jain%Erlang.dec@decwrl.dec.com
Also, we would presenting the scheme in detail at the next NBS/OSI implementors
workshop in october.
-Raj