Hi Jonathan:
>>> I've been trying to parse another of your mails on the same subject
>>> and
>>> still fail to understand the model you have in mind for what goes
>>> in the
>>> mesh header if any and what is uncompressed over a multihop LowPAN
>>> path.
>>> I believe that a few examples with figures would help a lot and that
>>> they should end up in the architecture doc once we agree on them.
>
>The Mesh Addressing header is currently defined in RFC4944 and the
>addresses carried within that header identify the end-points of an IP
>hop. With L3 forwarding, the Mesh Addressing header contains the same
>addresses as the 802.15.4 header and so the Mesh Addressing header can
>be elided. I've provided a few examples at the WG meetings. Can you
>tell me what specific scenarios you're confused about, so I can
>address them directly?
Say the path over a LoWPAN from a node A to a Backbone Router BbR is via
B and C
Say A sends a packet to D that is reachable over the BbR that acts as
default
gateway and 6LoWPAN termination for the LoWPAN.
A---->B---->C---->BbR---------->D
<-----------------> <----------->
LoWPAN Backbone
How I see things:
If we use a mesh header then it will show (A->BbR) all the way through
the LoWPAN
In particular, between B and C, it seems to me that the frame should
have:
- (b->c) in the MAC hdr;
- (a->BbR) in the mesh header;
- and indicate in the HC that A address is compressed whereas D is not.
That seems to work whether the routing is computed at L2 or L3.
Now if you do not have a mesh header, I fail to understand:
1) How the receive interface in C knows that the 6LowPAN continues
(it is not the LoWPAN endpoint so it should not reassemble)
2) How we make sure that all fragments reach BbR for reassembly.
Pascal
>-----Original Message-----
>From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>Sent: vendredi 30 mai 2008 17:33
>To: Jean Philippe Vasseur (jvasseur)
>Cc: Pascal Thubert (pthubert); Philip Levis; Mark Townsley (townsley);
[email protected]
>Subject: Re: Complete reassemble at every hop (was: [6lowpan] New
charter for 6lowpan)
>
>
>Hi Pascal and JP, see below:
>On May 29, 2008, at 7:16 PM, JP Vasseur wrote:
>>>> 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.
>>
>> Oops ! You mean route a fragment based on the routing decision made
>> for the
>> first fragment ? Not sure I personally like this, since this
>> introduces some
>> states on intermediate nodes, which has strong implication.
>> Further, this means that a fragmented packet cannot be rerouted
>> along a
>> backup path once the first fragment has been sent out since nodes
>> along the
>> alternate path would not have the required states to route them.
>
>Yes, it does consume extra state, but the overhead is pretty small,
>around 10-bytes for caching two tags, two addresses, and timing
>information. When the last fragment rolls by, you can quickly clean up
>the state. It's still an open question for me how may simultaneous
>flows of fragmented datagrams is truly needed. Re-routing mid-stream
>is arguably less important for delivering a fragmented datagram,
>especially due to temporal properties of the link.
>
>> 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.
>>>>
>>>
>>> This should be addressed in the architecture very clearly. Whether
>>> the
>>> path is computed at L2 or L3, there's a need to decide and express
>>> clearly in the packet what is the source that does the 6LowPAN
>>> compression, and what is the destination that expands the packet. An
>>> interface on a router should not have to make assumptions on
>>> whether a
>>> packet will be routed on another interface of the same type or not.
>
>Yes, I've said all along that the architecture document is necessary.
>Where reassembly happens has been pretty clear in my mind, and must
>happen before you exit a 6lowpan-based IP link.
>
>>> I've been trying to parse another of your mails on the same subject
>>> and
>>> still fail to understand the model you have in mind for what goes
>>> in the
>>> mesh header if any and what is uncompressed over a multihop LowPAN
>>> path.
>>> I believe that a few examples with figures would help a lot and that
>>> they should end up in the architecture doc once we agree on them.
>
>The Mesh Addressing header is currently defined in RFC4944 and the
>addresses carried within that header identify the end-points of an IP
>hop. With L3 forwarding, the Mesh Addressing header contains the same
>addresses as the 802.15.4 header and so the Mesh Addressing header can
>be elided. I've provided a few examples at the WG meetings. Can you
>tell me what specific scenarios you're confused about, so I can
>address them directly?
>
>--
>Jonathan Hui
>
>>>
>>>
>>> Fair?
>>
>> Indeed.
>>
>> Cheers,
>>
>> JP.
>>
>>>
>>> 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
