Subject: [6lowpan] Re: [sp100.11a-pdnt] Re: Transport layer requirements; first cut

From: Kris Pister <[email-masked]>
Date: Mon, 29 Oct 2007 12:00:36 -0700

yes, that much is clear. 
But why number 8 byte chunks instead of 15.4 payloads?
When the originator fragments the packet, it's going to break it up into 
a small number of fragments that fit into mesh/mac/phy payloads, not a 
byte stream with unknown (and shifting?!? "fragment overlap"?!?) boundaries.
I don't get the 16 bit datagram tag either.  That implies that we might 
be sending thousands of separately fragmented datagrams during the 
timeout+transit period for a single one?  The radio can't even do that 
at 100% duty cycle.
It seems like even with the 5 bits for the frag-type, this could all 
have fit into 2 bytes, not 5.

So with the 1280 requirement, and use cases that I understand, I get 2 
bytes.  Are there other things that I'm missing that lead to 4 and 5 
bytes for first and subsequent?

ksjp

Geoff Mulligan wrote:
> The design was based on the requirement to support 1280byte MTU to IP.
>
> 	geoff
>
> On Mon, 2007-10-29 at 10:43 -0700, Kris Pister wrote:
>   
>> Discussing simple ERP seems like a worthy sp100 topic, but it probably
>> doesn't matter that much if you believe my claim that even 1280 byte
>> datagrams will arrive with all fragments intact >99% of the time.
>>
>> Can anyone explain why 6LoWPAN chose such a funky fragment header?
>> They must have been trying to address something important to spend so
>> many bytes on it.
>>
>> ksjp
>>
>> Pascal Thubert (pthubert) wrote: 
>>     
>>> Hi Kris:
>>>
>>> Resending one lost fragment under the fragmentation sub-layer would be
>>> neat indeed.
>>>
>>> IBM's SNA employed error recovery procedures (ERP) at layer 2, in
>>> particular SDLC, LAPB and 802.2. Note that none of these can actually
>>> resend a specific piece and all require orderly delivery. HPR's RTP
>>> could do it but was very confidential, mostly used with IBM's parallel
>>> Sysplex.
>>>
>>> TCP supports but does not like out of order. Fast recovery is quickly
>>> triggered.
>>>
>>> I'd be interested in discussing the requirements for an ERP at DLL. I'm
>>> not sure that it is in scope for ISA100.11a right now, is it? I do not
>>> mean it's wrong, just that we are considering real issues, and real
>>> solutions.
>>>
>>> Pascal
>>>
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: Kris Pister [mailto:[email-masked]]
>>>> Sent: Sunday, October 28, 2007 10:30 PM
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: Phy/DLL/Network/Transport group
>>>> Subject: Re: [sp100.11a-pdnt] Re: Transport layer requirements; first
>>>>     
>>>>         
>>> cut
>>>   
>>>       
>>>> * fragmentation
>>>> Here's the way that I see fragmentation:
>>>> Mote A fragments the packet.  The first fragment contains the
>>>> fragmentation info and a delete/ARQ mode bit and time limit: "if you
>>>> haven't seen all 9 segments in 30 seconds, either {delete what you
>>>>     
>>>>         
>>> have}
>>>   
>>>       
>>>> or {send me a message saying which ones you're missing}".
>>>> These packets work their way through the network, potentially over many
>>>> paths, each arriving at its destination potentially out of order but
>>>> with over 99.9% probability.  The receiving mote reassembles the lot,
>>>> and checks the transport MIC on the entire thing (no transport MIC per
>>>> segment, just DLL MIC).
>>>> If we can't hit 100B of transport payload per packet, we need to go
>>>>     
>>>>         
>>> back
>>>   
>>>       
>>>> and fix 6LoWPAN (well, actually I already know that we have to fix
>>>> 6LoWPAN), so your TFTP chunk will take no more than 6 fragments no
>>>> matter what the security level is.  So the probability of losing one or
>>>> more segments is less than 1%.  Even a 1280B chunk should have less
>>>>     
>>>>         
>>> than
>>>   
>>>       
>>>> 1% probability of a missing segment.  I can't *prove* that, but I have
>>>>     
>>>>         
>>> a
>>>   
>>>       
>>>> LOT of data from real deployments to support the assertion.
>>>> But even if the probability is high that one or more segments is lost,
>>>> the timeout for ARQ included in the source makes things simple, and the
>>>> ARQ itself keeps things from being too inefficient - you don't throw
>>>>     
>>>>         
>>> out
>>>   
>>>       
>>>> 95% of a chunk, you just ask for the last 5% (if that's the way that
>>>>     
>>>>         
>>> the
>>>   
>>>       
>>>> sender requested it - some applications may want to explicitly say to
>>>> throw them away if they haven't all arrived by a certain time).
>>>> Motes can have a default timeout for fragment sets for which they have
>>>> not yet received the first fragment.
>>>>
>>>> I'm guessing that these ideas are not new, and that if I knew the IETF
>>>> literature better I'd be able to point to an RFC that describes
>>>> something like this.
>>>>
>>>> ksjp
>>>>
>>>> Pascal Thubert (pthubert) wrote:
>>>>     
>>>>         
>>>>> [...]
>>>>> [Pascal] That was the beginning of this thread. A major drawback of
>>>>> fragmentation is that if most frags for a packet make it but not all
>>>>>       
>>>>>           
>>> of
>>>   
>>>       
>>>>> them, the whole effort is wasted because the packet can not be
>>>>> reassembled and it will retried or lost. More than that, resources
>>>>>       
>>>>>           
>>> are
>>>   
>>>       
>>>>> locked on the receive side for some time waiting for the frag that
>>>>>       
>>>>>           
>>> will
>>>   
>>>       
>>>>> never come. If fragments are not in order, the situation is very hard
>>>>>       
>>>>>           
>>> to
>>>   
>>>       
>>>>> even detect. So it is generally better to send a flow on a same path
>>>>>       
>>>>>           
>>> so
>>>   
>>>       
>>>>> that if something goes wrong a given flow is fully impacted or not
>>>>> impacted at all.
>>>>>
>>>>> Say we do a file transfer for software image to a mote. TFTP will
>>>>>       
>>>>>           
>>> chunk
>>>   
>>>       
>>>>> it into 512 bytes TPDUs. Those will make around 8 or 9 6LoWPAN
>>>>>       
>>>>>           
>>> fragments
>>>   
>>>       
>>>>> if security is high. If the fragments are disseminated on many
>>>>>       
>>>>>           
>>> different
>>>   
>>>       
>>>>> path and one fragments gets lost because one path is faulty, the
>>>>>       
>>>>>           
>>> effort
>>>   
>>>       
>>>>> for carrying all the other fragments is more than a waste. It
>>>>>       
>>>>>           
>>> actually
>>>   
>>>       
>>>>> locks resources in the receiving mote for a long time. If we have
>>>>>       
>>>>>           
>>> less
>>>   
>>>       
>>>>> that 90% reliability, that means that most packets will never make it
>>>>> through integrally. If we have a number of transfers going on, it
>>>>>       
>>>>>           
>>> might
>>>   
>>>       
>>>>> happen that the full bandwidth of the network is used, and nothing is
>>>>> actually received at transport layer, and all the available memory is
>>>>> locked in the motes.
>>>>>
>>>>> Obviously, if 99.999% packets make it through thanks to path
>>>>>       
>>>>>           
>>> redundancy
>>>   
>>>       
>>>>> and retries, then the problem is much less visible and the benefits
>>>>>       
>>>>>           
>>> of
>>>   
>>>       
>>>>> the simple mechanism that Rick detailed prevail. I'm just unsure
>>>>>       
>>>>>           
>>> where
>>>   
>>>       
>>>>> the limit is, so I'm pointing out the potential threat and proposing
>>>>> classical techniques in place for that containing that risk. Maybe we
>>>>> can prove it's not needed and I'm sorry for wasting your time but at
>>>>> least we can document the case; or maybe it might happen to be needed
>>>>> and I proposed a simple hash to mitigate the risk. There are also
>>>>>       
>>>>>           
>>> more
>>>   
>>>       
>>>>> complex solutions in the art of mesh that use Forward Error
>>>>>       
>>>>>           
>>> Correction,
>>>   
>>>       
>>>>> network coding, or even an LLC with Error Recovery Procedure (like
>>>>> 802.2) to alleviate that risk...
>>>>>
>>>>>
>>>>> Pascal
>>>>>
>>>>>       
>>>>>           
>> --- You are currently subscribed to sp100.11a-pdnt as:
>> [email-masked] To unsubscribe send a blank email to
>> [email-masked]
>>     
>
>   
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 29 Oct 2007 14:34:46 -0700

The frag tag was originally 10-bits, but feedback from IESG review 
indicated that 10-bits was not enough. Many on this list (including me) 
thought that 10-bits was more than sufficient for practical use cases. 
But under what is possible, a node with 100% duty cycle could send 
enough frames to cycle through 1024 frag tags in 60 seconds. If you do 
the calculation, you'll find that 15.4 radios can send well more than 
2048 frames in 60 seconds. So the decision came down to decreasing the 
60s timeout or increasing the number of bits. The WG chose the latter. 
BTW, the overall frag header in the 10-bit version was 3 octets for 
first and 4 octets for subsequent. The discussion is archived here: 
http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00588.html

The decision on the use of frag size was before my time, but from what I 
can tell, the format was originally derived from RFC2734. The offset was 
reduced to save some bits. This optimization makes less sense with the 
expansion of the frag tag, but we already very deep in the process. I 
assume that an explicit offset was chosen because it gives flexibility 
in having different header lengths between frames.

--
Jonathan Hui

Kris Pister wrote:
> ------------------------------------------------------------------------
>