Hi Julien,
On Aug 19, 2008, at 12:57 AM, Julien Abeille (jabeille) wrote:
However, reassembly at every hop in a route over topology is really
bad.
Is it? From a network-layer perspective, yes. But from a whole system
perspective, it is much less clear. Sending fragments for a datagram
along a single path can be advantageous for many reasons. There are a
number of dynamic link-layer optimizations that reduce transmit costs,
increase throughput, and decrease latency, but, those mechanisms often
assume that they can amortize the initial setup costs over multiple
subsequent frames. You get to take advantage of the temporal
properties of a link. It is feasible to perform hop-by-hop fragment
recovery. Fragments arrive in order, making reassembly simpler at the
receiver.
We should think about a solution to the issue, or at least document
it somewhere if we cannot find a way around it.
Agreed.
--
Jonathan Hui
Best,
Julien
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: lundi 18 août 2008 21:38
To: Jean Philippe Vasseur (jvasseur)
Cc: Julien Abeille (jabeille); [email protected]
Subject: Re: [6lowpan] fragmentation and HC2
Hi JP,
I don't think your statement is entirely true. L3 forwarding at each
radio hop only requires fragmentation/reassembly at each radio hop.
I guess you could argue this is 1-hop mesh under (subsequent
fragments know the next-hop destination based on forwarding
information from the first fragment), but if you're doing L2
fragmentation, I don't see any way around it.
Maybe I'm not understanding your model, so let me try to reiterate
it and you can tell me where I'm wrong - you have datagrams
fragmented at L2 and you want to forward those fragments at L2 using
L3 information.
That model seems a bit strange to me and I'm not sure how it would
work if you have an IPv6 HBH Options header to process. It would
seem cleaner just to say that we're fragmenting at L3. At that point
I'd rather just stick a fragmentation header after the L3 addressing
information, but then that's starting to look awfully like an IPv6 +
fragment header. I know you're trying to find a middle ground so
that we can forward fragments using L3 information so that we can
avoid hop-by-hop fragmentation/reassembly and not violate the IPv6
min MTU requirement. I'd like to see that too. Is it okay to say
that, yes, we are doing L3 fragmentation but that those fragments
must be reassembled before exiting the 6lowpan network?
--
Jonathan Hui
On Aug 18, 2008, at 12:10 PM, JP Vasseur wrote:
Hi,
On 8/18/08 7:45 PM, "Jonathan Hui" <[EMAIL PROTECTED]> wrote:
There are multiple implementations (route-over and mesh-under)
that successfully utilize the current format today. If you want
addressing information in each L2 fragment, then forward at L2. If
you want to forward everything at L3, then fragment hop-by-hop. L3
routing is agnostic to the specific layer that forwarding occurs.
JP> this was not Julien’s point: depending on how you fragment you
may or you may not (in this case) be able to route at each hop of
course. Without addressing info in each fragment, this implies L2
forwarding and thus a mesh-under solution.
Thanks.
JP.
--
Jonathan Hui
On Aug 18, 2008, at 10:35 AM, JP Vasseur wrote:
Which requires a mesh under solution and does not work with route
over ....
Thanks.
JP.
On 8/11/08 6:39 PM, "Jonathan Hui" <[EMAIL PROTECTED]> wrote:
On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
Does fragment 2 look like:
FRAGN dispatch, datagram size, tag and offset | HC1 dispatch |
HC1 encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed
source and dest UDP port | UDP checksum | rest of UDP payload
or
FRAGN dispatch, datagram size, tag and offset | HC1 dispatch |
HC1 encoding =0x FA | IPv6 hop limit | rest of UDP payload
Neither. Everything after the frag header is considered part of
the fragmented payload.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
