mckee@MITRE.ARPA (H. Craig McKee) (11/24/88)
In a recent paper for the ACM, "The Design Philosophy of the DARPA
Internet Protocols" David Clark notes that: "The original ARPANET
host-to-host protocol provided flow control based on both bytes and
packets. This seemed overly complex, and the designers of TCP felt
that only one form of regulation would be sufficient"
He then describes the strengths and weaknesses of byte versus packet
flow control and acknowledgement.
He concludes by observing, "In retrospect, the correct design
decision may have been that if TCP is to provide effective support of
a variety of services, both packets and bytes must be regulated, as was
done in the original ARPANET protocols."
What flow control/acknowledgement procedure did ISO adopt for
Transport and Connectionless Mode services? dzoey@TERMINUS.UMD.EDU (11/25/88)
> From: H. Craig McKee <mckee@mitre.arpa> > What flow control/acknowledgement procedure did ISO adopt for > Transport and Connectionless Mode services? TP0 (simple class) There is no flow control/ack procedures. It relies entirely on the network layer for flow control & reliability. This is analogous to UDP's handling of flow control/ack (i.e. it doesn't). TP1 (basic error recovery class) Uses whatever flow control the network layer provides. There is an option to provide ACK of data if so desired. In this case, the source must hold onto the non-acked packets until they are acked. However, there is no credit (window) information in this class, so it's entirely up to the source as to how many packets get sent w/o an ack. TP2 (multiplexing class) If explicit flow control is not being used (an option), the no flow control takes place at the transport layer. If explicit flow control is being used (the default), a windowing system based on the number of packets is used. Each side of the connection advertises the number of "credits" that it will give. For each packet transmitted, the credit number is reduced by one. An ACK includes updated credit information. Credit windows may not be prematurely reduced. A packet that is outside the credit limit is a protocol error. For expedited data, there is no credit, and (I believe) lock step is used. Resequencing out of sequence packets is not mentioned. TP3 (error recovery and multiplexing class) Same as TP2 with flow control except that credit windows may be prematurely reduced. Packets received outside the window prompt a REJECT TPDU to be sent. It seems that REJECT provides a resync capability. Out of sequence packets also prompt a REJECT. TP4 (error detection and recovery class). Similar to TP2 with flow control, except that ACKS may have sub-sequence numbers to differentiate multiple transmitted ACKS with the same ack value. Resequencing of packets is defined. An out of window packet causes a transmit of an ACK with the correct credit and ack value. A method similar to keep alives is used to determine the state of the connection over long innactive periods. A lot of retransmission issues and whys and wherefores are discussed in ISO 8073. GOSIP endorses transport class 0 and 4. In addition, I have heard of implementations of TP2. TP4 is designed for use on non-reliable network connections. In the standard, TP4 doesn't directly refer to the TP{2,3} flow control mechanism, but the definition seems to be superset. I may be wrong because reading ISO standards is a new experience in confusing abbreviations. Does anyone know what the unabreviated version of the credit field indicator (YR-TU-NR) is? Joe Herman University of MD. dzoey@terminus.umd.edu
tozz@hpindda.HP.COM (Bob Tausworthe) (12/02/88)
>Does anyone know what the unabreviated version of the >credit field indicator (YR-TU-NR) is? ---------- In a AK (acknowledgement) packet, YR-TU-NR is the sequene number of the next expected DT (data) TPDU. In an EA (expidited ack) packet, YR-TU-NR is the id number of the ED (expidited data) TPDU being acked. In a RJ (reject TPDU) packet, it is the sequence number indicating the next expected TPDU from which retransmission should occur. However, you probably knew that. What the abbreviation stands for is : -- I don't know. I used to. I thought I had written it down in my copy of the standard but no such luck. TU-NR i believe stands for TransportUnit - NextREcieve but that's the easy part. YR escapes any logical detection Sorry and good luck tozz@hpinddf.hp.com