Subject: [6lowpan] fragmentation and HC2

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 11 Aug 2008 10:40:29 +0200

Hi,
 
I have a question regarding the use of HC2 together with fragmentation
in RFC4944:
When sending a large fully compressable UDP packet, must all fragments
contain HC_UDP encoding, or only the first one?
 
i.e.,  if the IP packet has flow label and traffic class = 0, payload
length inferred from L2, next header = UDP, source and destination
addresses link local with interface identifier inferred from L2
addresses, UDP length inferred from IP length field , and  I need 2
fragments:
 
In all cases, fragment 1 should look like :
FRAG1 dispatch, datagram size and tag | HC1 dispatch | HC1 encoding =
0xFB | HC2encoding | IPv6 hop limit | compressed source and dest UDP
ports | UDP checksum | beginning of UDP payload
 
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
 
Thank you,
Julien
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 11 Aug 2008 09:39:16 -0700

On Aug 11, 2008, at 1:40 AM, Julien Abeille (jabeille) wrote:
> encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed source  
> and dest UDP port | UDP checksum | rest of UDP payload
> or

Neither. Everything after the frag header is considered part of the  
fragmented payload.

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Mon, 18 Aug 2008 19:35:41 +0200

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-masked]> wrote:

>> 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
> 
> 
>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 18 Aug 2008 10:45:44 -0700

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.

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Mon, 18 Aug 2008 21:10:03 +0200

Hi,

On 8/18/08 7:45 PM, "Jonathan Hui" <[email-masked]> wrote:

> 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
> 
> 
>  
> 
>>>> encoding = 0xFB | HC2encoding | IPv6 hop limit | compressed source and dest
>>>> UDP port | UDP checksum | rest of UDP payload
>>>>   
>>>>  or 
>>>>   
>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 18 Aug 2008 12:37:36 -0700

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:

>> 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
>>
>>
>>
>>
>>>>>  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
>>>>
>>>>
>>>>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 19 Aug 2008 09:57:59 +0200

Hi Jonathan, JP,
 
from a layer perspective, I agree it makes sense in a route over topology to reassemble at every hop. It also makes sense to use the same L3 next hop for all fragments, as IP layer will select the next hop, then ask 6lowpan layer to send, and 6lowpan layer only knows wether fragmentation is needed, and even that fragmentation exists.
 
However, reassembly at every hop in a route over topology is really bad. We should think about a solution to the issue, or at least document it somewhere if we cannot find a way around it. 
 
Best,
Julien

________________________________

From: Jonathan Hui [mailto:[email-masked]] 
Sent: lundi 18 août 2008 21:38
To: Jean Philippe Vasseur (jvasseur)
Cc: Julien Abeille (jabeille); [email-masked]
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

	Hi,

		
		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

		

			 Thanks.
			 
			 JP.

			

					 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

				
________________________________

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 20 Aug 2008 08:02:23 -0700

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

> 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.
>
> 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  
> 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
>
>
>
>>> There are multiple implementations (route-over and mesh-under)  
>>> that successfully utilize the current format today. If you want

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 Aug 2008 18:43:48 +0200

Hi:

I'm just back fro vacations so I jump in late in this discussion. We discussed this already in the "[6lowpan] Mesh-header, do we need it anymore?" thread. 

Please review what was discussed there. My understanding Is that today, we need to expand the packets at each L3 hop, which includes recomposing when there are fragments but is costly even when the packet is not fragmented.

I'd wish to actually work on forwarding the compressed form when we can, fragmented or not. This is not possible today but could be done if we had a (compressed) routing header and/or could use 16bit addresses as labels.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui
Sent: mercredi 20 août 2008 17:02
To: Julien Abeille (jabeille)
Cc: [email-masked]
Subject: Re: [6lowpan] fragmentation and HC2

Hi Julien,

	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

	Hi JP,

	

	--

	Jonathan Hui

	

	Hi,

	

	
	Thanks.
	
	JP.

	--
	Jonathan Hui

	

	 
	 Thanks.
	 
	 JP.

	

	

	  
	 or 

	
	 
	 --
	 Jonathan Hui