Subject: [Int-area] Comments to ALFI

From: "Cao Zhen (cz)" <[email-masked]>
Date: Mon, 5 Nov 2012 13:56:56 -0500

Hi Carsten,

The problem you describe is cool. But in Lwig guidance document, I
remember there is a guidance saying we should avoid fragmentation if
we can. And also applications are also diet in 6lowpan, so I am not
sure the case we envision fragment problem.

The fact is that in Internet today only has very very few fragments,
due to the fact of MTU configuration/discovery and also TCP MSS
option. I donot the case of the internet of things though.

I think I am not the only lucky guy to have not witnessed any fragments:)

Thanks,
cz

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 14:11:38 -0500

On Nov 5, 2012, at 13:56, "Cao Zhen (cz)" <[email-masked]> wrote:

> we can.

Yes, but how do you do that if you don't know the fragment size?
Right now, you can only guess, and you'll likely try to guess conservatively, missing out on the opportunity to reasonably fill the packets.

> And also applications are also diet in 6lowpan, so I am not

Indeed, simple sensor readings/actuator settings are unlikely to trigger fragmentation.
Unfortunately, when the need for bulk data arises (firmware updates, configuration changes), it often is needed for many nodes in the network, which means the speed at which you can perform these operations at scale depends on the efficiency you can get.

> option.

Yes.  We have ways to find out the IP MTU and therefore mostly can avoid fragmentation if our protocols are set up for that.
My problem statement is that we can't do that at the adaptation layer.
We simply didn't provide a way to find out the fragment sizes for the adaptation layer.

> I think I am not the only lucky guy to have not witnessed any fragments:)

Lucky you :-)

Please have a look into the 6lowpan packet repository at
http://svn.tools.ietf.org/svn/wg/6lowpan/packets/
if you want to see 6LoWPAN fragmentation in action...

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Nov 2012 11:34:21 -0800

Hi, all,

On 11/5/2012 10:56 AM, Cao Zhen (cz) wrote:
> Hi Carsten,
>
> The problem you describe is cool.

Can someone summarize that to the list? I don't think I saw it.

There have been a lot of recent discussion on v6ops about fragmentation 
as well, notably on a recommendation they are considering to "drop all 
fragments" due to the overhead of processing any IPv6 options.

I claim:

a) if processing is an issue, then they could ask to recommend "drop 
IPv6 with any options", but dropping only fragments could easily require 
more extensive chained-header processing for routers

b) dropping all options isn't viable

Others have claimed that it's reasonable for a port filter device to 
drop all fragments and send back PTB messages. Here are my concerns with 
that approach:

- PTB messages themselves are already filtered by the same kind of 
operators who insist on routers doing port filtering

- sending PTB to a host that has fragmented might not help; if it 
could/wanted to adjust the TCP or UDP segment size, it would already 
have done so. since IPv6 fragmentation happens at the source, the likely 
result is just a lot of smaller fragments (which isn't useful)

I am now considering whether a port filter device may need to reassemble 
IPv6 fragments. IMO, if such a device isn't in a network location where 
such reassembly is reasonable (i.e., on behalf of a host whose entire 
traffic it controls), then port filtering there isn't reasonable anyway. 
Yes, such reassembly might be considered to violate RFC 2460, but so 
does "drop all fragments" or "drop any options". Arguably any device 
that checks port numbers is acting either as the destination or a proxy 
for the destination anyway.

> But in Lwig guidance document, I

That's advisable anywhere, and already in RFC 2460.

> option. I donot the case of the internet of things though.

I'm not sure we're seeing the whole situation; fragments happen over 
tunnels too, many of which are secure and we might not be able to notice.

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 14:48:06 -0500

> Can someone summarize that to the list? I don't think I saw it.

The segment in intarea today was about adaptation layer fragmentation indication,
draft-bormann-intarea-alfi-01.txt

That is fragmentation that is harder to avoid, as it happens "transparently" below IP in an adaptation layer for a specific link layer.
I was arguing for providing a "looking glass" into what is happening down there, so transport or application layer protocols can choose packet sizes intelligently.  The specific solution I was proposing was mainly a strawman to show how it could be made to work in principle -- the hop-by-hop option I used may be not very useful in the general Internet.

Grüße, Carsten

---

From: "Cao,Zhen (cz)" <[email-masked]>
Date: Mon, 5 Nov 2012 15:28:09 -0500

> Right now, you can only guess, and you'll likely try to guess conservatively, missing out on the opportunity to reasonably fill the packets.

Only 6lowpan adaption is here in IETF, the MTU is 127 bytes, isn't it?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 16:49:16 -0500

> Only 6lowpan adaption is here in IETF, the MTU is 127 bytes, isn't it?

That is the physical layer MTU.

The specific combination of MAC layer overheads, adaptation layer overheads, and header compression gains can turn the actual initial fragment size number into anything roughly between 70 and 160 bytes.  Note that this is more than a factor of two.

Grüße, Carsten

---

From: "Cao,Zhen (cz)" <[email-masked]>
Date: Tue, 6 Nov 2012 09:28:08 -0500

> The specific combination of MAC layer overheads, adaptation layer overheads, and header compression gains can turn the actual initial fragment size number into anything roughly between 70 and 160 b…

This worth stating in the draft though:)

regards, cz