Hi Jonathan:
Jonathan:
>>The third issue is whether or not end-to-end mechanisms should be used
>>for recovery and congestion control. I think we agree that hop-by-hop
>>mechanisms are required regardless. They increase reliability and can
>>provide effective congestion control and mitigation. To me, hop-by-hop
>>mechanisms are generally much more effective than end-to-end ones
>>because they react to local conditions and can quickly provide back-
>>pressure all the way to the source. From a reliability standpoint,
>>we've seen solutions deliver >99.9% without end-to-end recovery. So
>>one question is how much more reliability do we really need? and does
>>it justify the added energy overhead and code size?
Phil:
>This is an excellent point. On one hand, it is critical that we do not
preclude end-to-end recovery >mechanisms, at the very least for the end-
to-end argument. On the other, we might be getting a bit >ahead of
ourselves here; it's not clear at all whether the benefits of these
mechanisms (increased >layer 3 delivery ratios) significantly outweigh
their costs (code size and energy).
Pascal:
For the sake of clarity for anyone reading this thread, the discussion
here is about end-to-end LoWPAN path not end-to-end IP path. We have
been discussing whether fragmentation can happen end-to-end and here the
question is about flow control and recovery.
- for flow control I'd argue that the source should be throttled but if
possible not all the hops on the way one by one. Hop by hop flow control
leads to a general and slow backoff all the way to the source that will
impact other connections which should not be impacted.
- for recovery, some level of hop by hop recovery helps fro sure but
there are limits. For instance is inteferences jam a given node, all the
retries will fail, even if it has an alternate next hop. Also, if you
have built a graph made of non congruent paths, then end to end retry
enables to try an entirely new path. I suspect a mix of the 2 can do
better.
About the cost of it, well we need to design simple and low overhead. I
listed a number of requirements in my draft:
Number of fragments
The recovery mechanism must support highly fragmented packets,
with a maximum of 32 fragments per packet.
Minimimum acknowledgement overhead
Because the radio is half duplex, and because of silent time spent
in the various medium access mechanisms, an acknowledgement
consumes roughly as many resources as data fragment.
The recovery mechanism should be able to acknowledge multiple
fragments in a single message.
Controlled latency
The recovery mechanism must succeed or give up within the time
boundary imposed by the recovery process of the Upper Layer
Protocols.
Support for out-of-order fragment delivery
A Mesh-Under load balancing mechanism such as the ISA100 Data Link
Layer can introduce out-of-sequence packets. The recovery
mechanism must account for packets that appear lost but are
actually only delayed over a different path.
Optional flow control
The aggregation of multiple concurrent flows may lead to the
saturation of the radio network and congestion collapse.
The recovery mechanism should provide means for controlling the
number of fragments in transit over the LoWPAN.
Backward compatibility
A node that implements this draft should be able to communicate
with a node that implements [RFC4944]. This draft assumes that
compatibility information about the remote LoWPAN endpoint is
obtained by external means.
More in:
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover
y
Pascal
>-----Original Message-----
>From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>Sent: mardi 27 mai 2008 18:27
>To: Pascal Thubert (pthubert)
>Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley
(townsley); [email protected]
>Subject: Re: [6lowpan] New charter for 6lowpan
>
>
>Hi Pascal, I see a few underlying issues in this discussion.
>
>First is whether or not route-over implies complete reassembly at
>every hop. In my view, it doesn't. A node could simply cache the
>datagram tag when the first fragment arrives and forward the
>subsequent fragments accordingly. Note that this also saves header
>overhead because the mesh header doesn't have to be included in every
>fragment. When forwarding between different links, reassembly has to
>happen anyway.
>
>The second issue is whether or not we constrain forwarding fragments
>of a given datagram to a single path. This is where mesh-under and
>route-over diverge. But to me, there are a lot of advantages to
>constraining delivery of a datagram to a single path. Hop-by-hop
>recovery can ensure in-order delivery. Hop-by-hop congestion control
>becomes much more meaningful. It's unclear to me what end-to-end
>congestion notification means in a mesh-under setting. We can also
>take advantage of link optimizations to increase throughput and
>decrease latency. And, as mentioned before, reduces header overhead by
>not needing addressing information in subsequent fragments.
>
>The third issue is whether or not end-to-end mechanisms should be used
>for recovery and congestion control. I think we agree that hop-by-hop
>mechanisms are required regardless. They increase reliability and can
>provide effective congestion control and mitigation. To me, hop-by-hop
>mechanisms are generally much more effective than end-to-end ones
>because they react to local conditions and can quickly provide back-
>pressure all the way to the source. From a reliability standpoint,
>we've seen solutions deliver >99.9% without end-to-end recovery. So
>one question is how much more reliability do we really need? and does
>it justify the added energy overhead and code size?
>
>--
>Jonathan Hui
>
>
>
>On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote:
>
>> Hi Phil:
>>
>> We do agree on the problem.
>>
>> Per-hop reassembly, though, comes at the expense of that traffic
>> fluidity that was so desirable to the ATM designers. In other words,
>> because per-hop reassembly forces each intermediate node to store and
>> forward a full packet, it is augmenting the latency of the flow and
>> the
>> memory requirements on the forwarding nodes on the way.
>>
>> This is why I had in mind to couple a few per-hop recovery with a
more
>> solid end-to-end recovery and flow control mechanism between the
>> LoWPAN
>> endpoints.
>>
>> Now I wonder what this discussion becomes in route over v.s. mesh
>> under.
>> In route over, it seems that the forwarding node terminates a link
>> so it
>> has to reassemble before it forwards on a different link that might
or
>> might not be a LoWPAN; so maybe we end up doing the same thing in
that
>> case.
>>
>> Jonathan, what do you think?
>>
>> Pascal
>>
>>> -----Original Message-----
>>> From: Philip Levis [mailto:[EMAIL PROTECTED]
>>> Sent: vendredi 23 mai 2008 19:46
>>> To: Pascal Thubert (pthubert)
>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley);
>> [email protected]
>>> Subject: Re: [6lowpan] New charter for 6lowpan
>>>
>>>
>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote:
>>>
>>>> Hi JP:
>>>>
>>>> I see your concern.
>>>>
>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, and
>>>> that
>>>> the basic operation is pretty simple: emulate a packet loss in RED
>> but
>>>> save the packet. So the real problem is not ECN itself but what RED
>>>> becomes in a LowPAN forwarding node. And that is something that the
>>>> node
>>>> will have to define whether it does ECN or RED.
>>>>
>>>> If we do not have ECN then the LowPAN forwarding nodes will have to
>>>> destroy frames which might be fragments. Considering the cost of
>>>> energy
>>>> and bandwidth to getting the frame up to that forwarding node, the
>>>> latency introduced by transport layer time out, and the risk of
>>>> congestion collapse introduced by resending the whole segment, I'd
>>>> suggest that ECN is actually a good idea.
>>>
>>> This gets back to the point I brought up December 14, 2006. In lossy
>>> networks, end-to-end fragmentation and assembly is a real problem.
It
>>> makes much more sense to do per-hop fragmentation and assembly. In
>>> the
>>> former, the number of retransmitted fragments is exponential in the
>>> number of hops; in the latter, it is linear.
>>>
>>> Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
