ronald@robobar.co.uk (Ronald S H Khoo) (01/17/91)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > On the contrary, X terminals would benefit from a good asymmetric splitting > of bandwidth. But PEP doesn't give you split bandwidth, it gives you half duplex with extremely high cost to turn the line around. Now, if you had a link-level protocol that reduced the number of turnrounds by letting whole windows through before letting the other side speak, you might win. SLIP doesn't do this though, and my cursory glance at PPP doesn't show such an option there either (though I'd be glad to be told that I'm wrong). Am I ? Does such a protocol exist ? -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey) (01/18/91)
In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > > > On the contrary, X terminals would benefit from a good asymmetric splitting > > of bandwidth. > > But PEP doesn't give you split bandwidth, it gives you half duplex with > extremely high cost to turn the line around. Now, if you had a > link-level protocol that reduced the number of turnrounds by letting > whole windows through before letting the other side speak, you might > win. SLIP doesn't do this though, and my cursory glance at PPP doesn't > show such an option there either (though I'd be glad to be told that I'm > wrong). Am I ? Does such a protocol exist ? > Both SLIP and PPP only look as far as the IP header for clues on delivery. Even this may be considered too much of a bleed into the network layer when a point-to-point data-link is involved. Both Van Jacobson's Compressed SLIP and his extensions to PPP look as far as the TCP header to determine compressability. If SLIP or PPP were to provide TCP window optimization over the data-link, then it would have to really dig into both the TCP header and the TCP options to determine window size/status, etc. While sometimes these optimizations are necessary to give a product an edge in the market, I usually shy away from code that is *too* smart. I tend to think that better optimization of IP over half-duplex links can be done with smarter queuing algorithms coupled with starvation prevention measures. On the local machine, this may actually give the feeling that entire windows are being sent at once, since all the segments may be queued in one shot from the TCP code. --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/18/91)
In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > > > On the contrary, X terminals would benefit from a good asymmetric splitting > > of bandwidth. > > But PEP doesn't give you split bandwidth, it gives you half duplex with > extremely high cost to turn the line around. ... I was trying to say is that a magical way to automatically and dynamically allocate bandwidth between the two directions would be better than any fixed allocation, including 50/50. Whether this magic would consist of devoting 100% of the bandwidth to one direction for X% of the time and 100% of the bandwidth to the other direction for (100-X-Z)% of the time (ie. what is often called "half duplex") is an separate issue. It may be that at the low speeds and analog phone lines being discussed, no such magic is possible, or that the magic would cost too many bits computed as [sum (wasted bandwidth*wasted time)]. I've not been initiated into the right kinds of wizardry to know. It is obvious that if you must fix the allocation between the two directions (if the system including modems cannot change this allocation as traffic or other conditions warrent) and if your traffic is "general," then 50/50 is the best general purpose answer (e.g. v.32), provided 50% of the total is gives usable performance. It seems obvious that an old fashioned, half-duplex 2400 b/s modem with would support X traffic less badly than a 1200 b/s full duplex modem, despite the long turn-around times of such old hdx modems. At medium and high speed, things tend to be more dynamic. Imagine how slow ethernet would be if the ~10MHz were permanently partitioned into rx and tx allocations for each station. (Common, commercially available, relatively low cost workstations move >1MByte/sec through TCP/IP/ethernet.) Sheesh! I didn't realize I was so mumble-mouthed to be repeatedly misunderstood on such an obvious point. Vernon Schryver, vjs@sgi.com