Date: Mon, 12 Oct 1998 11:21:06 +0100 From: Brian Somers <brian@Awfulhak.org> To: Kenjiro Cho <kjc@csl.sony.co.jp> Cc: Brian Somers <brian@Awfulhak.org>, current@FreeBSD.ORG Subject: Re: Improper sharing of modem bandwidth Message-ID: <199810121021.LAA00663@woof.lan.awfulhak.org> In-Reply-To: Your message of "Mon, 12 Oct 1998 12:38:44 %2B0900." <199810120338.MAA07249@hotaka.csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> Brian, > > How hard do you think it is to add the following feature to the > userland ppp? > > The issll working group at IETF > (http://www.ietf.org/html.charters/issll-charter.html) > proposes a suspend/resume style transmission method: > "PPP in a real-time oriented HDLC-like framing". > (http://www.ietf.org/internet-drafts/draft-ietf-issll-isslow-rtf-03.txt) > > The basic idea is that, if a FIFO based serial chip is used, we are > able to control the transmission of each byte so that we can suspend a > low-priority packet in the middle of the transmission. > In the above draft, the frame format and the negotiation format is > defined as an extension to the PPP Multilink fragmentation protocol. > > With the packet-by-packet control, the latency is more than 500 ms > over 64Kbps with 1500-byte MTU. > I believe that the latency of telnet will be less than 50 ms even in > the middle of ftp, if the suspend/resume is implemented. This is all quite plausible, but with a couple of caveats, both of which, after a cursory glance at the above pages, I didn't see included. The first problem is the tty buffer. Ppp, when passed a fragment, will (usually) attempt to write the whole thing to a non-blocking tty. The tty will already have reported (via select()) that it's writable. Short writes will be continued the next time the descriptor tells select() it's writable. This phenomena is likely to affect latency calculations - the bigger the tty buffer, the greater the latency would be - despite suspend/resume. I don't know if a kernel implementation would have any more control over this sort of thing though, and this isn't a show-stopper by any means. The second problem is that a packet/fragment must be compressed (if (link level) CCP has been negotiated) prior to transmission. Any traffic that wants to be sent during the transmission of a compressed fragment must either a) be sent uncompressed b) be sent compressed using a different dictionary c) wait for the rest of the interrupted packet on the remote end so that the remote can decompress in the correct order. a) Problems may arise for the server->client traffic as it may increase to a point where we're better off avoiding the suspend/resume altogether. Even the client->server traffic may cause problems as VJ compression would become difficult to implement. Maybe a way out would be to insist that only VJ-compressed (if VJ was negotiated) packets may cause a suspend/resume - but this may cause even more problems on a ppp implementation that doesn't update its VJ slots 'till *after* a packet has been received (rather than doing so as soon as it receives the new TCP/IP header). b) Treating interactive & non-interactive traffic as two completely separate streams would be quite clean. VJ and CCP would need to duplicate their slots/dictionaries - one interactive and one non-interactive set. c) This option is useless - it shows why we'd need to do either a) or b). Having said all that, I've talked myself into b) being a good method. The memory overhead isn't outrageous, the duplicated dictionaries will have no adverse effect AFAICT, and it will work for both uni and multi-link mode. I wonder if it would be necessary to allow interactive-fragment VJ and CCP options - ie, someone wants VJ and no CCP for interactive traffic, but CCP and no VJ for non-interactive traffic. This might improve interactive latency further. > --Kenjiro -- Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org> <http://www.Awfulhak.org>; Don't _EVER_ lose your sense of humour.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810121021.LAA00663>