2

Will transferring over PPP data stream containing only reserved bytes 0x7E, 0xFF, 0x03 reduce bandwidth by 50% because of escaping?

Then it seems to be very stupid if not say moronic. Such poor design still widely used in PPPOE, PPTP, L2TP and many other linked network stacks. Am I missing something? The example with transferring only one of magic bytes may seem to be kind of extreme case but it is still possible in some time periods. Magic bytes may occur in data stream more or less frequently but the principle itself is depressing.

Improve this question
7
  • 13
    Might I suggest more polite way to phrase questions? For example, something along the lines I do not understand why such seemingly inefficient method was chosen instead of [what they did] seems to be very stupid / moronic would probably be better received. Always assume that the problem is in you not understanding something, and not that everyone else is the idiot. And always make a room for a doubt that you misunderstood something. BTW, I upvoted because the idea behind the question is valid, but tone of the question might be why people downvote and/or decide to ignore it.
    – Matija Nalis
    Feb 5, 2020 at 21:18
  • It seems rather irrelevant to practical real-world use since transmission of any network traffic without encryption at the transport layer is completely unreasonable and backwards in this decade (or even in this century).
    – R.. GitHub STOP HELPING ICE
    Feb 5, 2020 at 22:13
  • 1
    @R..GitHubSTOPHELPINGICE I have to disagree: there are many, many, places that use internet protocols which aren't connected to the internet, such as industrial telemetry, and there is no real purpose served in encrypting those. For internet traffic, perhaps it's better to encrypt at a different layer. Should encryption be built into ethernet?
    – jonathanjo
    Feb 6, 2020 at 9:09
  • 1
    Please put the question in the question text, not just the title, which should just be a summary of the question.
    – Barmar
    Feb 6, 2020 at 10:08
  • Obviously, someone who is trying to DoS your network by sending a constant stream of magic bytes will not encrypt them.
    – user253751
    Feb 6, 2020 at 12:02

1 Answer 1

Reset to default
20

You might care to read RFC 1547 "Requirements for an Internet Standard Point-to-Point Protocol" which explains how the PPP was chosen. The thing I'd suggest you are missing is that interoperability is one of the principal driving forces in the internet protocols, and efficiency is much less important. You do the highly talented engineers who designed PPP a disservice in describing their work as "stupid/moronic/depressing". They solved an extremely large class of problem with a very general, extensible, protocol -- and, much more difficult, got everyone to agree on it. It's a tribute to its quality that many systems still use PPP, and many new uses are found for it, after 30-odd years.

From the motivation section of of RFC 1134, "The Point-to-Point Protocol: A Proposal for Multi-Protocol Transmission of Datagrams Over Point-to-Point Links":

One reason for the small number of point-to-point IP links is the lack of a standard encapsulation protocol. There are plenty of non- standard (and at least one defacto standard) encapsulation protocols available, but there is not one which has been agreed upon as an Internet Standard. By contrast, standard encapsulation schemes do exist for the transmission of datagrams over most popular LANs.

To directly answer your question, PPP over asynchronous serial does do octet-stuffing (ie, 0x7e is encoded as 0x7d, 0x5e). It does this for the Flag Sequence (0x7e), the Control Escape (0x7d) and control characters (0-0x1f). This is defined in RFC 1549 "PPP in HDLC-Like Framing". The control character which need escaping can be negotiated by the Link Control Protocol option Async-Control-Character-Map.

Yes: A frame consisting entirely of octets which require escaping would indeed have a bandwidth reduction approaching 50% on large frames. It's not clear to me why you describe this in such disparaging terms: it's a perfectly ordinary framing mechanism designed for compatibility with very many different serial links, interoperability across implementations, and reliability. How else would you propose to do it?

But No: Over ethernet there is no octet-stuffing. See RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"

Improve this answer
7
  • The only alternative to an escape sequence is a size field in the header - requires the sender to know the size early enough though. Excellent answer, jonathanjo!
    – Zac67 ♦
    Feb 5, 2020 at 14:45
  • @Zac67 Thanks for compliment (high praise, coming from you!) A size field is good enough for framing in a synced situation but doesn't guarantee resynchronisation after an error so I would say doesn't really qualify as an alternative.
    – jonathanjo
    Feb 5, 2020 at 15:02
  • 1
    Absolutely, resynchronization without outer framing is a serious problem as well. :-)
    – Zac67 ♦
    Feb 5, 2020 at 15:03
  • "How else would you propose to do it?" - Since what @Zac67 said won't quite work, what about allowing the control characters to be dynamically renegotiated? Then if one side knows it has to send a lot of literal control characters and both sides agree they can choose new control characters and the overhead of escaping things becomes much less. Though upon skimming the answer again, I guess that's basically what the Async-Control-Character-Map does?
    – aroth
    Feb 6, 2020 at 6:13
  • @aroth the gist of the question is about quoting in general; ACCM only means you don't have to quote 0x0-0x1f if your OS can send them cleanly, the standard still requires escaping the flag and the escape. The result is that every single 0x7e is a framing flag and every 0x7d is a an escape which makes the framing/escaping algorithm simpler and more robust. It's possible to devise a more complex escaping mechanism (next N octets are escaped) which is more space efficient but any analysis of real data shows you should be compressing headers or compression of payload across packets eg HTTP.
    – jonathanjo
    Feb 6, 2020 at 9:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.