6 ms·

How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread

How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread of misinformation: - IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has to send a packet that doesn't fit through the path MTU. - The end points use Packet Too big ICMP6 messages to determine _path_ MTU, which is different from just "the MTU". - With IPv4, the sender chooses whether a router will fragment when the packet exceeds the next-hop MTU or whether the router should drop the packet and send a Fragmentation Needed ICMP message - where the latter again is used for path MTU discovery. - Path MTU discovery is useful because it allows the sending IP implementation to push the chunking higher up the stack when the sending higher-level protocol has the capability (as is the case with TCP, but not with UDP, for example), which tends to produce lower overhead. Unfortunately, some clueless firewall administrators, such as those responsible for AWS EC2, do filter all ICMP because they for unknown reasons consider it to be bad, thus breaking PMTUD, which can lead to hanging TCP connections. - TCP sequence numbers are for bytes, always, with the special case of SYN and FIN also counting as "bytes" in the sequence, but never for segments.

the_cat_kittles 13y ago
Just out of curiosity, what do you do? Is this knowledge germane to where you work? I've just recently become interested in this stuff, so I'm curious to get a lay of the land.
- zAy0LfpBZLC8mAC 13y ago
  I do ... software development? ;-) There isn't really any particular category for what I do, though I tend to do more of the lower-level/backend stuff of projects, and knowing how the stuff that you build on works internally certainly is useful in optimizing and debugging. As for getting an understanding of how TCP/IP works, I think Stevens' classic TCP/IP Illustrated still is a good book to get started, even if somewhat dated in some details (no IPv6, in particular), but the general principles still apply. Though maybe there are newer equally good books around that I just don't know about?
  - bendavis381 13y ago
    The networking section of Unix and Linux System Administration Handbook has some excellent explanations of TCP/IP and many other networking topics.
  - frankzinger 13y ago
    TCP/IP Illustrated has a new edition (volume 1 only for now, AFAICT) which has been updated with much more modern content, including lots of info about IPv6: http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 http://www.informit.com/store/tcp-ip-illustrated-volume-1-th...
    - zAy0LfpBZLC8mAC 13y ago
      Well, yeah, it's a book by the same name, but is it the same quality (well, it's not just the same name, of course, but a new author obviously can make a big change in quality, in either direction ;-)? In any case, my recommendation was referring to the old edition by Stevens alone, no clue about the new one, though at least the newly covered material seems appropriate to me. (For anyone who might not be aware: W. Richard Stevens died in 1999, so the new edition is by a different author, though apparently based on the old material.)
      - frankzinger 13y ago
        I have not worked through the entirety of the original, which I also own, but the new one seems pretty good to me so far. But you may have a different opinion as somebody who knows much more than me about TCP/IP.
mhurron 13y ago
> "minimum payload size" (whatever that is) I'll give them the benefit of the doubt and say he got his terms wrong. The IPv6 RFC states that IPv6 requires a minimum MTU of 1280 bytes. I guess that's what he meant. https://www.ietf.org/rfc/rfc2460.txt https://www.ietf.org/rfc/rfc2460.txt Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
- zAy0LfpBZLC8mAC 13y ago
  Which wouldn't really make me any more confident in the reliability of the whole thing?! Confusing lower-level fragmentation and reassembly with IPv6 fragmentation is not exactly a mistake you'd be likely to make when you understand what that actually means, I would think.
  - mhurron 13y ago
    It would be one you would make as you were learning it, which is honestly what half the blogs that cross here are. It just happens that the neat thing this person learned today was about some networking protocols they use every day.
  - yeukhon 13y ago
    Let's not guess and help correct the article, shall we? Documentation, manpage, textbook and programming books can contain errors. On the flip side, I like to see more people helping critiquing these articles so newbies like me can get the most out of it (though I already took computer network...).
unethical_ban 13y ago
I love it when people without deep knowledge of a subject try to learn about it and explain themselves to others.
- stusmall 13y ago
  This is an important part of the way I learn. I will read something and then explain it to someone else. It makes me think deeper about the issue as I form the words and it gives me a great chance to get corrected when I am making unfair assumptions. I always preface this conversations with "as I understand it" or "from what I read" or some other disclaimer. I used to have a coworker who would give me soooo much guff about these disclaimers since I'd drop so many of them in one of these conversations. I just felt it was important to make it clear I wasn't coming from a place of authority and more from the perspective of a guy who is bumbling through it and trying to figure out what the hell is going on.
  - Jugurtha 13y ago
    It's the way I learn, too.. But it doesn't make me write things as a guy who's knowledgeable. I'm a total noob, yet the first few paragraphs made me cringe because I felt there were some odd things. I had a weird feeling about it. It wouldn't have bothered me if there wasn't this "A periodical about best practices and advanced techniques in Objective-C".. Or using the word "great contributors", etc. I mean, one has to be humble because unless one really knows his stuff, he shouldn't talk that way. If the writing style was more in the "I'm learning and journaling my progress", it would've been more than okay, and knowledgeable people wouldn't have a problem with it. I was in forums and learning to design my PCB's, I'd post my design and ask for feedback, and people who'd spent 30+ years would comment on them and point flaws on what I thought was nice and would find a thousand flaws in it. And I got back to wrok, iteration after iteration.. Until these really great guys who do that for a living would say "Beautiful work". Had I posted something like "advanced PCB design" in the "this is how it's done" way, they'd have ignored me and I would've stayed more ignorant than I still am. There was a question on the Python mailing list asking how long it takes to say that one knows how to program. People with 40+ years actively programming said: I'll let you know when I'm there. Humility goes a long way. Heck even when I read things on the nmap mailing list, I don't feel that tone that they consider they know more than you do even though they really, really know their stuff.
cbsmith 13y ago
I'm also going to cut him some slack with the bit about giving each segment a unique number. While formally the sequence number identifies each byte of data, it really is about providing heuristics to identify and correct for out of order, fragmented, missing & duplicate segments. It is important that it be about bytes, particularly for things like SACK, but if you are trying to simplify things you might describe it as being about the segments.
- zAy0LfpBZLC8mAC 13y ago
  Sure, nothing wrong with simplifying things, but "Both ends are sending sackOK. This will enable Selective Acknowledgement. It switches the sequence numbers and acknowledgment number to use byte range instead of TCP segment numbers." is just flat-out wrong, and in particular suggests that "numbered segments" is not a simplification but an actual fact about how the thing works.
  - danieleggert 13y ago
    Thanks for taking the time to point this out. I'll update the article.
cbsmith 13y ago
And regarding dropping the ICMP message about fragmentation... good firewall implementations have the firewall discover the MTU behind it and express THAT.. even better they might hide the hops behind it.
- zAy0LfpBZLC8mAC 13y ago
  There is no such thing as an "MTU behind it", there is a separate path MTU for each and every ordered address pair, more or less (and that's not even static, obviously). And obviously I was talking about packet filters, not about some kind of application firewall, which obviously doesn't have anything to do with filtering of packets anyhow.
shadesandcolour 13y ago
From the editorial page of this issue: "We’ve created a new public repository on GitHub that contains all current and past objc.io articles. If you find any mistakes or have suggestions for improvements, please don’t hesitate to file issues, or even better: submit a pull request!" Make a pull request so that people like me can learn about networking too.
jakejake 13y ago
Anybody writing routing code would be foolish to use this, or any other "simplified" article as a protocol reference. But, I'll agree that it is presented in such a way (and with enough technical detail) that any technical errors should be corrected. If I had deep knowledge in this area, I'd probably applaud the effort and send corrections, rather than criticize.
danieleggert 13y ago
Thanks for taking the time to comment on the article. I'll update the article later today to correct these. Your help is appreciated.
Myrmornis 13y ago
What an unpleasant attitude. The author clearly made a lot of effort and as far as I know it's all accurate. If you know better then say so pleasantly.

the_cat_kittles 13y ago

Just out of curiosity, what do you do? Is this knowledge germane to where you work? I've just recently become interested in this stuff, so I'm curious to get a lay of the land.

zAy0LfpBZLC8mAC 13y ago
I do ... software development? ;-) There isn't really any particular category for what I do, though I tend to do more of the lower-level/backend stuff of projects, and knowing how the stuff that you build on works internally certainly is useful in optimizing and debugging. As for getting an understanding of how TCP/IP works, I think Stevens' classic TCP/IP Illustrated still is a good book to get started, even if somewhat dated in some details (no IPv6, in particular), but the general principles still apply. Though maybe there are newer equally good books around that I just don't know about?
- bendavis381 13y ago
  The networking section of Unix and Linux System Administration Handbook has some excellent explanations of TCP/IP and many other networking topics.
- frankzinger 13y ago
  TCP/IP Illustrated has a new edition (volume 1 only for now, AFAICT) which has been updated with much more modern content, including lots of info about IPv6: http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 http://www.informit.com/store/tcp-ip-illustrated-volume-1-th...
  - zAy0LfpBZLC8mAC 13y ago
    Well, yeah, it's a book by the same name, but is it the same quality (well, it's not just the same name, of course, but a new author obviously can make a big change in quality, in either direction ;-)? In any case, my recommendation was referring to the old edition by Stevens alone, no clue about the new one, though at least the newly covered material seems appropriate to me. (For anyone who might not be aware: W. Richard Stevens died in 1999, so the new edition is by a different author, though apparently based on the old material.)
    - frankzinger 13y ago
      I have not worked through the entirety of the original, which I also own, but the new one seems pretty good to me so far. But you may have a different opinion as somebody who knows much more than me about TCP/IP.

mhurron 13y ago

> "minimum payload size" (whatever that is) I'll give them the benefit of the doubt and say he got his terms wrong. The IPv6 RFC states that IPv6 requires a minimum MTU of 1280 bytes. I guess that's what he meant. https://www.ietf.org/rfc/rfc2460.txt https://www.ietf.org/rfc/rfc2460.txt Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

zAy0LfpBZLC8mAC 13y ago
Which wouldn't really make me any more confident in the reliability of the whole thing?! Confusing lower-level fragmentation and reassembly with IPv6 fragmentation is not exactly a mistake you'd be likely to make when you understand what that actually means, I would think.
- mhurron 13y ago
  It would be one you would make as you were learning it, which is honestly what half the blogs that cross here are. It just happens that the neat thing this person learned today was about some networking protocols they use every day.
- yeukhon 13y ago
  Let's not guess and help correct the article, shall we? Documentation, manpage, textbook and programming books can contain errors. On the flip side, I like to see more people helping critiquing these articles so newbies like me can get the most out of it (though I already took computer network...).

unethical_ban 13y ago

I love it when people without deep knowledge of a subject try to learn about it and explain themselves to others.

stusmall 13y ago
This is an important part of the way I learn. I will read something and then explain it to someone else. It makes me think deeper about the issue as I form the words and it gives me a great chance to get corrected when I am making unfair assumptions. I always preface this conversations with "as I understand it" or "from what I read" or some other disclaimer. I used to have a coworker who would give me soooo much guff about these disclaimers since I'd drop so many of them in one of these conversations. I just felt it was important to make it clear I wasn't coming from a place of authority and more from the perspective of a guy who is bumbling through it and trying to figure out what the hell is going on.
- Jugurtha 13y ago
  It's the way I learn, too.. But it doesn't make me write things as a guy who's knowledgeable. I'm a total noob, yet the first few paragraphs made me cringe because I felt there were some odd things. I had a weird feeling about it. It wouldn't have bothered me if there wasn't this "A periodical about best practices and advanced techniques in Objective-C".. Or using the word "great contributors", etc. I mean, one has to be humble because unless one really knows his stuff, he shouldn't talk that way. If the writing style was more in the "I'm learning and journaling my progress", it would've been more than okay, and knowledgeable people wouldn't have a problem with it. I was in forums and learning to design my PCB's, I'd post my design and ask for feedback, and people who'd spent 30+ years would comment on them and point flaws on what I thought was nice and would find a thousand flaws in it. And I got back to wrok, iteration after iteration.. Until these really great guys who do that for a living would say "Beautiful work". Had I posted something like "advanced PCB design" in the "this is how it's done" way, they'd have ignored me and I would've stayed more ignorant than I still am. There was a question on the Python mailing list asking how long it takes to say that one knows how to program. People with 40+ years actively programming said: I'll let you know when I'm there. Humility goes a long way. Heck even when I read things on the nmap mailing list, I don't feel that tone that they consider they know more than you do even though they really, really know their stuff.

cbsmith 13y ago

I'm also going to cut him some slack with the bit about giving each segment a unique number. While formally the sequence number identifies each byte of data, it really is about providing heuristics to identify and correct for out of order, fragmented, missing & duplicate segments. It is important that it be about bytes, particularly for things like SACK, but if you are trying to simplify things you might describe it as being about the segments.

zAy0LfpBZLC8mAC 13y ago
Sure, nothing wrong with simplifying things, but "Both ends are sending sackOK. This will enable Selective Acknowledgement. It switches the sequence numbers and acknowledgment number to use byte range instead of TCP segment numbers." is just flat-out wrong, and in particular suggests that "numbered segments" is not a simplification but an actual fact about how the thing works.
- danieleggert 13y ago
  Thanks for taking the time to point this out. I'll update the article.

cbsmith 13y ago

And regarding dropping the ICMP message about fragmentation... good firewall implementations have the firewall discover the MTU behind it and express THAT.. even better they might hide the hops behind it.

zAy0LfpBZLC8mAC 13y ago
There is no such thing as an "MTU behind it", there is a separate path MTU for each and every ordered address pair, more or less (and that's not even static, obviously). And obviously I was talking about packet filters, not about some kind of application firewall, which obviously doesn't have anything to do with filtering of packets anyhow.

shadesandcolour 13y ago

From the editorial page of this issue: "We’ve created a new public repository on GitHub that contains all current and past objc.io articles. If you find any mistakes or have suggestions for improvements, please don’t hesitate to file issues, or even better: submit a pull request!" Make a pull request so that people like me can learn about networking too.

jakejake 13y ago

Anybody writing routing code would be foolish to use this, or any other "simplified" article as a protocol reference. But, I'll agree that it is presented in such a way (and with enough technical detail) that any technical errors should be corrected. If I had deep knowledge in this area, I'd probably applaud the effort and send corrections, rather than criticize.

danieleggert 13y ago

Thanks for taking the time to comment on the article. I'll update the article later today to correct these. Your help is appreciated.

Myrmornis 13y ago

What an unpleasant attitude. The author clearly made a lot of effort and as far as I know it's all accurate. If you know better then say so pleasantly.