yes. quite a bit else that was hashed out on the 6lowpan mailing list
during the design of the 6lowpan header formats.
geoff
On Mon, 2007-10-29 at 12:00 -0700, Kris Pister wrote:
> 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 PROTECTED]
> > > > > 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 PROTECTED] To unsubscribe send a blank email to
> > > [EMAIL PROTECTED]
> > >
> >
> >
> --- You are currently subscribed to sp100.11a-pdnt as:
> [EMAIL PROTECTED] To unsubscribe send a blank email to
> [EMAIL PROTECTED]
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
