Ted Lemon <mellon@xxxxxxxxx> wrote:
> The reason I’m concerned about this is that it’s my understanding that
> generally on LLNs fragments are acknowledged at the packet level, not
> at the fragment level. This means that if five fragments are
> transmitted and one dropped, all five have to be retransmitted. This
> assumption may actually not be true—I haven’t tested it. It’s based on
> what others have told me about how this works. If this assumption isn’t
> true, then my primary concern goes away. The concern I have is that as
> packet loss rates rise, the likelihood of any given IP packet making it
> across an 802.15.4 mesh intact (with no fragments lost) drops. Because
> every fragment has to be retransmitted, this can result in a lot of
> extra traffic being sent, which can further increase packet loss.
There is always a terminology issue, because things got overloaded in my opinion.
RFC4944 was never clear enough for my liking, and overloads "fragment"
So let me be clear:
frame: a thing transmitted at layer 2
fragment: a part of an IP packet that has undergone fragmentation
fraglet: a sometimes used term for "fragmentation" at layer 2.
segment: a part of a TCP transmission that can be ACKnowledged
packet: a IP packet as we know it.
LLNs usually take packets which are 1280 or less and turn them into fraglets
("fragments") for transmission through the LLN. Many LLN technologies
including 802.15.4 provide to ACKs for each transmission, and there is a
retransmission a few times, but then it stops and goes on. Does this result
in an immediate loss of the entire packet? Yes, often.
RFC4944 says that each node re-assembles the fraglets to a packet at each
hop, and then tries again. But, we have proposals for fraglet forwarding.
IP can, of course, fragment a packet into many IP fragments, each of which
can be transmitted on their own, to be assembled by the end points, not the
intermediate nodes.
TCP works best if you never create IP fragments, so setting the segment size
to what can efficiently get through the LLN is good.
I'm sorry to repeat, but I think we've done ourselves a disservice by not
being more precise.
> So if that’s true, it makes sense to keep the mss short, preferably
> shorter than 1280. 1280 would be thirteen fragments on 802.15.4, if my
> math is right. I think ideally we’d want to keep the MSS down nearer to
> 500 bytes.
It sounds right that an *MSS* of 1280 would be 13 fraglets on 802.15.4.
I think that if you set the MTU to 1280, you get an MSS smaller than 1280 though.
> It may be that my reasoning is completely wrong here, but the reason
> for my reaction to this document is that this is my present
> understanding of the problem, and hence the recommendation of a 1280
> byte mss seems wrong. If I misread that, I apologize. As I said, I
> need to give the document a closer read. Generally speaking I would
> really like to see the old canard that TCP can’t work on LLNs put to
> pasture, so I want this work to succeed. Again, I’m sorry for the
> unkind comment.
The fraglet forwarding proposal would more reliably forward larger IP
packets, so a larger MSS might actually be more efficient use of energy.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
