Subject: [6lowpan] tentative rev 12 format draft: draft-ietf-6lowpan-format-12.txt

From: gabriel montenegro <[email-masked]>
Date: Tue, 20 Mar 2007 00:29:47 -0700 (PDT)

Chairs,

I've modified the draft to address IESG comments based on recent exchanges, and created a tentative version 12 available at:

    http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-12.txt

Chairs, please double check and submit if it's fine.

-gabriel

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Mar 2007 11:22:20 +0100

On Mar 20 2007, at 08:29, gabriel montenegro wrote:

> Chairs,
>
> I've modified the draft to address IESG comments based on recent  
> exchanges, and created a tentative version 12 available at:
>

Looks good to me.

Thanks for catching the "one-bit" remnant.

I'd rather have deleted the first indented paragraph of the  
justifying text starting 10.
If we keep it, please add a full stop at the end of "usual flow-
aware schemes" (or maybe turn it into something more readable, such  
as "schemes that build separate context for each flow to be  
compressed").

The one remaining comment not covered is the justifying text under  
"datagram size", for which Jari supplied a comment.
I'd propose simply deleting the justification:

 >   Typically, this field needs to encode a maximum length of 1280
 >   (IEEE 802.15.4 link MTU as defined in this document), and as much
 >   as 1500 (the default maximum IPv6 packet size if IPv6
 >   fragmentation is in use).  Therefore, this field is 11 bits long,
 >   which works in either case.

(If we had wanted to explain anything about this field, it should  
have been that this is *NOT* the datagram size, but the IPv6 packet  
size, i.e. the result of any IPv6 fragmentation that may already have  
happened.)

Gruesse, Carsten

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Mar 2007 12:42:32 +0200

> From: Carsten Bormann <[email-masked]>

>  >   which works in either case.

Uhh.. the max IPv6 packet size is over 65Kbytes! It's just that
depending on MTU, it gets fragmented to smaller pieces on a specific
interface/link. Thus, this MTU (and resulting IPv6 packet size) is
whatever the 6lowpan decides to specify.

And, of course, the TCP protocol stack tries to avoid fragmenting, and
uses whatever size fits the MTU. But for UDP, the packet size is
totally under application control (like Blackberry sometimes uses(?)
4-8Kb UDP packets).

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Mar 2007 12:50:13 +0200

> From: Markku Savela <[email-masked]>

> Thus, this MTU (and resulting IPv6 packet size) is whatever the
> 6lowpan decides to specify.

Occurs to me, as 6lowpan does it's own internal fragmentation anyway,
it could actually advertise very large MTU (like 4-16Kb) to avoid IPv6
header overhead in bulk transfers. Whether sensible, depends how
likely the packet loss is on the link.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Mar 2007 11:52:19 +0100

On Mar 20 2007, at 11:42, Markku Savela wrote:

> Uhh.. the max IPv6 packet size is over 65Kbytes!

A couple of us may be aware of that (and even of Jumbograms) :-)

Another reason to remove this text.

(As a general rule, justifying text rarely is very useful in the body  
of a specification, and it often confuses more than it helps.  Also,  
as in this case, apparently nobody cared to proofread it as it is  
just justifying the actual contents of the specification.  It's like  
comments in programs; they are not tested and get out of date too  
quickly.  Another textbook example for our classes on protocol  
design...)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Mar 2007 11:54:32 +0100

On Mar 20 2007, at 11:50, Markku Savela wrote:

> header overhead in bulk transfers.

Well...

> Whether sensible, depends how

Exactly, and with a very small L2 MTU and losses exacerbated by  
possible multi-hop L2 paths, you really want L4/L7 reliability for  
larger ADUs.

Gruesse, Carsten