Subject: Re: SV: [6lowpan] WG last call on Format document

From: gabriel montenegro <[email-masked]>
Date: Sun, 7 Jan 2007 10:31:09 -0800 (PST)

Sounds good. 

By the way, Phil, I thought you meant changing the fragmentation/reassembly
algorithm outright, it was not clear to me that you just wished to relax the order
of the headers. 

I'd suggest capturing Phil's issue in the writeup used by the
chairs to advance the document as per:

   http://www.ietf.org/IESG/content/Doc-Writeup.html

That way we can invite discussion from the IESG on this item.

This concern (and perhaps the one related to extension dispatch headers as well)
could be mentioned in 1.d or in 1.k ("working group summary") in the Doc-Writeup.

-gabriel

----- Original Message ----
From: Schumacher Christian Peter Pii <[email-masked]>
To: Philip Levis <[email-masked]>; gabriel montenegro <[email-masked]>; [email-masked]; Geoff Mulligan <[email-masked]>
Cc: [email-masked]
Sent: Sunday, January 7, 2007 2:52:15 AM
Subject: SV: [6lowpan] WG last call on Format document

SV: [6lowpan] WG last call on Format document

Given the feedback, I believe the chairs can submit the documents for IESG review.

Regards

Christian

-----Oprindelig meddelelse-----

Fra: Philip Levis [mailto:[email-masked]]

Sendt: lø 1/6/2007 10:17

Til: gabriel montenegro

Cc: Schumacher Christian Peter Pii; [email-masked]

Emne: Re: [6lowpan] WG last call on Format document

On Jan 5, 2007, at 10:16 AM, gabriel montenegro wrote:

> On Comment 1: Reassembly: I don't think we should delay the draft 

> because of this.

> I think this is an interesting research topic. I notice that there 

> are similarities with

> the folks applying DTN to sensor networks (projects at UCLA's LECS, 

> SICS, Trinity College, etc).

> DTN is itself a research group in the IRTF, so similarly, I see 

> such extensions to LoWPAN

> as possible  alternatives once the basic draft in its current form 

> is done. One possible

> avenue is to reuse AODV to do the discovery of the DTN-capable 

> devices, and integrate with

> the routing layer such that the proper tradeoffs (end-to-end, hop-

> by-hop or anything in the

> middle) are possible. Such an approach was discussed recently at 

> the CHANTS workshop and

> IRTF DTNRG:

> paper:  http://doi.acm.org/10.1145/1162654.1162659

> slides: http://www3.ietf.org/proceedings/06nov/slides/DTNRG-11.pdf

> Such functionality should be worked on subsequent to the base spec.

My point isn't take the document should specify single-hop 

reassembly. It's that, as written, it precludes single-hop 

reassembly. If the spec were, for example, to say that the two 

headers could be in either order, then there would be no problem. My 

concern is that the document -- without any technical justification 

for the decision -- is digging itself into a hole where producing 

efficient (in terms of energy, RAM, and code space) implementations 

will be difficult. It might be that a new mesh2 header emerges that 

reverses the order, with the cost of a few extra bits in each packet.

That being said, there is the point to be made that large packets in 

6lowpan are expected to be very rare and mostly present for complete 

interoperability than for core use cases. So this might in the end be 

entirely irrelevant. Given the lateness in the process and lack of 

forward progress, having something is better than nothing. So I'll 

shelve my concern and am happy to agree on the document.

> I note that there is one remaining item which fell through the cracks:

> we need to define the format of future dispatch headers. The length 

> of the

> dispatch headers defined in the base spec is known, so protocol 

> parsing can

> proceed. For future dispatch headers, we need to include a length 

> field in

> a well-known place in the header, otherwise proper parsing is not 

> possible.

> This needs to be in the base spec.

I had thought that the discussion went down the road of "if you don't 

know the header type, drop the packet," keeping packet processing 

simple.

Phil

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Jan 2007 21:09:08 +0100

> That way we can invite discussion from the IESG on this item.

While it is always a good thing to obtain input from the IESG, I  
don't think delegating this issue to the IESG during document  
submission is the right approach here.

The WG is the domain expert on the kind of network we are discussing  
here.
The WG should come to a conclusion.
The IESG can then check that we followed process and that the  
document fits into the wider IETF picture (which is *not* dominated  
by the relevant considerations here).

<wg-chair hat="off">
   On the reassembly issue, I see two approaches:

   1) keep with the reassembly at destination
   2) open up the sequence such that reassembly-before-forwarding  
becomes an alternative, chosen by the sender.
   3) only allow reassembly before forwarding, i.e. forward only full  
datagrams.

   (As far as I can see, nobody argues for 3, that's why I see *two*  
approaches.)

   The advantage of 2 is more options (Philip has explained why this  
can be a good thing).

   The obvious disadvantage of 2 is more options (i.e., increased  
burden on an implementation).
   With 2, the sender gets to decide whether a forwarder has to  
reassemble before forwarding; the forwarder has to play with that  
decision.
   (Reassembly at the forwarder also means different fragments cannot  
choose different paths; maybe a more theoretical consideration.)
</wg-chair>

I'd like to hear more people taking sides on 1 or 2 before we declare  
consensus.

Gruesse, Carsten