For a good time you should see what satellite modems do! It makes sense since they need enormous buffers, but it's kinda fun to realize the modern next to you, even though it's not really operating at layer three, has chosen to effectively terminate your tcp session, ACKing you, and then buffers to the other modem, who has its own ACK protocol. Similarly on the other end. This is why non tcp, like pptp is so bad on satellite.
I'm curious to hear the practical implication of docsis on pptp performance. If you compare a native tcp to a pptp encapsulated tcp, do you notice a difference? -- Clark Gaylord [email protected] ... thumbed on Android auto-correct may have improved this message brevity should not be taken to imply curtness ... On Oct 7, 2015 4:16 AM, "Bless, Roland (TM)" <[email protected]> wrote: > Hi, > > Am 07.10.2015 um 09:42 schrieb LAUTENSCHLAEGER, Wolfram (Wolfram): > > Is this specialized upstream TCP ACK handling, particularly the > > prioritization a general recommendation in all access technologies? > > Perhaps it should be, since otherwise up and downstream TCP flows > interfere > > in a crazy queue oscillation that is typically misinterpreted by AQMs. > > Is this topic addressed in some RFC already? > > Oh, I hope that this is an exception. Such kind of > optimizations may cause a lot of trouble since a link > layer device is interfering with transport layer semantics. > We all know that exactly these kinds of interference > eventually end up in problems with end-to-end transparency and > deployment of new protocol options. At least it interferes with > the ACK clocking expectation of some congestion control algorithms... > > Regards, > Roland > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm >
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
