Re: [6lowapp] Where does TCP not work

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Jonathan:

We went around that same question of transport at ISA100.11a.

We ended up using a form of DTLS (over UDP) that 6LoWPAN actually
compresses efficiently.

Why did we end up with this?

- every app seemed to have very different requirement on transport. The
common ground was reduced to a secured datagram service.

- we resolved to use the CCM provided by the chipset crypto engines
(same as used at L2) to save power.

- ISA100 (client-server) apps that need ack usually have app layer ack
that carries some data back. Transport layer ack is there a costly and
unwanted operation.

- Most of the data (buffered, eg readings repeated over and over) do not
require retries anyway 

- packet loss during TCP start can delay the connection for too long
(that's what started reliable UDP to pass dial numbers that later became
SCTP)

- we considered other transports like DCCP but for a number of reasons
that include those middle boxes that know only TCP and UDP, we resolved
to stay with UDP with ECN passed up to the app layer.

Cheers,

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf Of Jonathan Hui
>Sent: mardi 3 novembre 2009 05:22
>To: Lars Eggert
>Cc: [e-mail]
>Subject: Re: [6lowapp] Where does TCP not work
>
>
>On Nov 2, 2009, at 7:46 PM, Lars Eggert wrote:
>
>> It's definitely debatable whether the approach that we've so far
>> followed (making links and lower-layer network technologies
>> implement stuff so that TCP/IP runs OK) is the One True Answer.
>
>Yes.
>
>> As we expand IP into environments that are very different from the
>> "normal" Internet, it's not fully clear (to me at least) whether
>> this approach will continue to be efficient. At the bar BOF in
>> Stockholm, I made a strawman proposal that for 6LOWAPPs, we might
>> instead start thinking about giving up on TCP and implementing a set
>> of end-to-end transport functions that apps can pick & choose from,
>> depending on their needs (reliability, uni/multicast, error
>> protection, loss protection/FEC, flow control, etc.) Those functions
>> may not need to be provided by a separate protocol with a header and
>> a layer in the stack; we might make them available as a common
>> library that apps link against, for example.
>
>Certainly sounds like an interesting idea and it would be a breath of
>fresh air not to be encumbered by TCP.  So can we afford to sacrifice
>interoperability with TCP-based tools/infrastructure?  There are
>clearly people on both sides and it's not clear to me how to come to
>closure except to recognize both sides for the time being.
>
>--
>Jonathan Hui
>
>_______________________________________________
>6lowapp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowapp