Date: Tue, 13 Oct 1998 14:19:34 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: Brian Somers <brian@Awfulhak.org> Cc: current@FreeBSD.ORG Subject: Re: Improper sharing of modem bandwidth Message-ID: <199810130519.OAA16223@hotaka.csl.sony.co.jp> In-Reply-To: Your message of "Mon, 12 Oct 1998 11:21:06 %2B0100." <199810121021.LAA00663@woof.lan.awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian, Thanks for your input. > How hard do you think it is to add the following feature to the > userland ppp? > [snip] >> 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. Surely, once the packet queueing delay is reduced, we need to reduce the tty delay. The current kernel doesn't have ioctls for the buffer size but slip uses a smaller tty buffer and has a better response time than ppp. When I was playing with ppp back in May, I used a smaller tty buffer and a smaller sio buffer, and found it helpful. (the code is available from http://www.csl.sony.co.jp/person/kjc/kjc/software.html#altq4ppp) >> 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 don't know much about this area but it seems to me that approach b) is reasonable and doable. >> 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. Isn't the sender allowed to switch encoding according to the priority and packet size? Anyway, this improvement seems to have a much smaller impact on the total performance. --Kenjiro 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?199810130519.OAA16223>