shri@ncst.ernet.in (H.Shrikumar) (12/27/90)
----------------------- [For comp.protocols.tcp-ip-ers ... There is this thread in Comp.dcom.modems talking about PPP and TCP/IP spoofing on Telebit modems. I am cross posting this for info ... all followups directed to comp.dcom.modems.] ----------------------- In article <BOB.90Dec26112824@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes: > >Correct. But I was talking about uucico (the program that typically >implements UUCP-g and can be considered the protocol layer "above" >UUCP-g), which knows only about complete files. Thanx Bob Sutterfield, for the much needed long post ... hopefully this will clear all doubting minds on this group. >An application based on TCP assumes a reliable, sequenced data stream. >[...] A TCP application assumes that any portion >of a transmission that has been ACKed has reached its destination, and [...deleted...] >If such a guarantee were possible, then your conclusion would be >correct. But a modem cannot guarantee packet delivery. If a modem >has ACKed a packet to the sender and continues to hold it in its >on-board memory buffer while it attempts to re-establish a connection, This is very correct. You hit the problem on the head. However, some spoofing is still possible. When TCP sees the long turnaround of ACKs via the slow (or delayed) PEP reverse channel, it may prefer to set rather inappropriate window sizes etc. However, by spoofing these packets, the two modems can tune their PEP packets to the IP packet size, the TCP window to the PEP window, which inturn will depend on line conditions and retransmission rates, and this can be dynamic. This will be at no extra (transmission) cost since surely the modems are already doing dynamic PEP adaptation already. Of course, this will make the line look error free to TCP, but my uneducated guess is that would not affect TCP too much. If it would, then some errors need to be spoofed as well to keep the algorithms in TCP happy. Would some C.P.TCP-IP-guru correct, if I am wrong ? The modem can also spoof VJ Header Compression, so plain vanilla slip can give good performance over the line. This is another spoofing possible. Thus, while the modem *should* *not* ACK any TCP packets, it can do other things to increase thruput. Howmuch of this does the Netblazer do ? Now howabout this ... the modem can also generate IP packets, and mix them into the stream coming from the telco side into the local host. These TCP or UDP packets could tell the computer about the health of the modem, and the local host can reply back and perhaps change modem settings etc. Each modem will need an IP address too, though. (This can be done with PPP, 'cos PPP is point to point). Sigh! but since as netBelief goes, Telebit does not read this group anymore ... so would they listen to this idea ? ( 1/2 :-) >I'm having trouble imagining at what level of the stack in-modem >protocol spoofing might be useful for IP or ISO internetworks, above >the data link layer. I haven't gotten around to testing synchronous >PPP over T2500s in PEP SDLC mode - has anyone? Is its performance >enough better than asynch PPP over asynch PEP to be worth the trouble? These results would be interesting ... has anybody any ? -- shrikumar ( shri@ncst.in )
bob@MorningStar.Com (Bob Sutterfield) (12/28/90)
In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar) writes:
However, some spoofing is still possible... by spoofing these
packets, the two modems can tune their PEP packets to the IP packet
size, the TCP window to the PEP window, which inturn will depend on
line conditions and retransmission rates, and this can be dynamic.
It might be useful to allocate a few DAMQAM carriers or the HST
"reverse channel" for use by ACKs and the like, or to fit the MTU to
the characteristics of the line (or vice versa); but I wouldn't call
it spoofing, only accomodation and tuning. The modem wouldn't know
anything about TCP, only that it's allocating bandwidth to packets of
certain sizes and characteristics.
Of course, this will make the line look error free to TCP, but my
uneducated guess is that would not affect TCP too much. If it
would, then some errors need to be spoofed as well to keep the
algorithms in TCP happy.
While TCP can handle line problems admirably, there's certainly no
need to introduce them except perhaps for performance tuning. No need
to spoof a flat tire by shooting it, just to keep me on my toes while
I'm driving :-)
The modem can also spoof VJ Header Compression, so plain vanilla
slip can give good performance over the line.
Hmmm... I'll have to think about that one a while longer before I'm
convinced. Something doesn't feel right.
Thus, while the modem *should* *not* ACK any TCP packets, it can do
other things to increase thruput.
Right, but that's not spoofing in the same sense that Telebit modems
use the term in their handling of other protocols. It's just tuning.
How much of this does the Netblazer do ?
None, except VJ header compression (computed on the PC, not in the
modem) across serial links it manages. It's a conventional enough IP
router, with no intermediate-system protocol spoofing at all.
... the modem can also generate IP packets ... tell the computer
about the health of the modem, and the local host can reply back
and perhaps change modem settings etc...
Link quality monitoring is among the purposes of the proposed PPP MIB
for SNMP. Rather than have the modem generate IP packets, I suppose
the contents of the Trailblazer's S7[02] (for PEP) or S78 (for V.32)
or various other status registers could be acquired via the secondary
DTE channel, and digested for broadcast as a pppLinkQualityEntry. But
that secondary DTE was turned off in the standalone T2500 v7.00 ROMs,
so slightly more cleverness would be required.