Subject: [tsvwg] : Q: transport recommendations for "routing protocols"

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Jan 2016 15:36:35 -0800

Are there any drats/RFC that would give me guidance if i wanted to design
packet exchanges hop-by-hop between eg: routers/switches, with traffic
patterns lets say like a routing protocol.

I see even new protocols like Babel run on top of datagram and have
all their own retransmission/ultimate-consistency schemes, and i was
wondering what opinions TSVWG has about this.

Or let me turn this around: I'd rather like to build a protocol that
just uses hop-by-hop TCP and not reinvent all the transport aspects
that go along with that (including remote adjacencies/tunnels across stupidly
bad internet adjacencies with jitter and loss). But the ongoing reality of
protocols like this does not seem to indicate that there's any evolving
wisdom that this would be a good thing.

And then the IOT space says TCP is bad, use CoAP, but then i don't even
have messagee exchanges anymore but put would ahve to reinvent it on top
of something like PUT/GET primitives... ? *sigh*

So, really wondering.

Thanks!
    Toerless

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Jan 2016 16:47:50 -0800

On 1/27/2016 3:36 PM, Toerless Eckert wrote:
> bad internet adjacencies with jitter and loss).

Isn't that basically e-mail routing?

(which, IMO, is a very reasonable replacement for the bulk of the
mechanisms underlying DTN).

Joe

---

From: <[email-masked]>
Date: Fri, 29 Jan 2016 04:23:10 +0000 (UTC)

We attempted to leverage hop-by-hop TCP, and avoid reinventing all the transport aspects, with HTTP-DTN:
http://http-dtn.sourceforge.net/
(The DTN bundling crowd wasn't interested, which suggests it's a good idea...) Lloyd Woodhttp://sat-net.com/L.Wood/dtn

      From: Joe Touch <[email-masked]>
 To: Toerless Eckert <[email-masked]>; [email-masked] 
Cc: [email-masked]
 Sent: Friday, 29 January 2016, 11:47
 Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols"

Joe

---

From: <[email-masked]>
Date: Fri, 29 Jan 2016 05:24:26 +0000 (UTC)

> of something like PUT/GET primitives... ? *sigh*

I know.

That's why we came up with http-dtn.

Then you could do RESTful exchanges, M2M with SOAP etc., on top of HTTP/TCP.
 
Lloyd Wood [email-masked] http://about.me/lloydwood 

________________________________
From: Toerless Eckert <[email-masked]>
To: [email-masked] 
Sent: Thursday, 28 January 2016, 10:36
Subject: [tsvwg] : Q: transport recommendations for "routing protocols"

So, really wondering.

Thanks!
    Toerless

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 29 Jan 2016 12:39:39 +0000

> wondering what opinions TSVWG has about this.

RFC5405 and 5405bis (which is past WGLC)

It focuses on UDP, but that obviously generalizes mostly to arbitrary datagram communication. 5405bis also now discusses multicast.

Lars

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 29 Jan 2016 16:43:41 -0800

Thanks Lars. I was aware of those documents.

I guess everybody can read different things between the lines of
this document. I for once read it in a way:

  Thanks for reading this UDP document. You thought you want to
  do UDP in your protocol/app because you think it simplifies
  life. Well, let us tell you all the things you really need to do
  that TCP is already doing for you anyhow, so building something
  on UDP is by far not as easy as you hoped unless you fail to
  comply with these requirements. (reading for unicast only of course ;-)

But i am past this point. I was hoping there is some RFC document
that even say: Do not bother with UDP, just use TCP, there is nothing
bad about it. Is there any ? IOT folks for once still seem to claim
that you can build significantly more lightweight protocol stacks over
UDP than TCP. How true is that ? How small would a device have to be
so that i would need to start worrying about TCP as a choice.

I'd be happy too if the recommendation was SCTP Maybe better ? My 
requirements are so lame that i can't see how any of its improvements would
make a difference. But i haven't gotten a good review if SCTP could be more
lightweight even than TCP.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Jan 2016 15:33:30 +1300

> so that i would need to start worrying about TCP as a choice.

I dunno. I just had to worry about this choice in some prototype code,
and to think about all the things I'd have to code to deal with UDP.
The answer was: too many for my poor little head, and why bother?

If somebody can provide a userland package that does for me
what SOCK_STREAM does, that would be fine. But I do not want to
know anything about checksums, out-of-order packets, lost packets,
retransmission, fragmentation, or reassembly.

> lightweight even than TCP.

If you want real robustness, why not MPTCP?

    Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 30 Jan 2016 07:12:45 +0000

Hi,

>  comply with these requirements. (reading for unicast only of course ;-)

that is the gist of it, yes. (Although for very simple/specialized uses without much future evolution, UDP can be a good starting point.)

> bad about it. Is there any ?

I don't think so, and I the reason is probably that this sentiment is certainly not a consensus the IETF has. UDP does have its uses, but requires much more clue to use correctly.

(Every time I read something along the lines saying "we chose UDP, because it's lightweight" I immediately begin to think the authors don't fully grok the complexities. If I read something that says "we don't need and don't foresee to need features X, Y and Z of TCP, and therefore build on UDP like this" I feel more confident of the proposed design.)

> IOT folks for once still seem to claim

The CORE WG has discussed this, and the claim is that there is a class of devices at the very low end for which TCP will remain prohibitive. (Because even if the more capable devices become cheaper, as an IoT customer you'd then rather spend your money on more nodes rather than the same number of more capable nodes.) Ask on the CORE or T2TRG lists?

> lightweight even than TCP.

I don't think the footprint is much different.

Lars

---

From: <[email-masked]>
Date: Sat, 30 Jan 2016 11:52:54 +0000 (UTC)

> But i haven't gotten a good review if SCTP could be more 

SCTP is heavier. More complex.
 Lloyd Wood [email-masked] http://about.me/lloydwood 

----- Original Message -----
From: "Eggert, Lars" <[email-masked]>
To: Toerless Eckert <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Saturday, 30 January 2016, 18:12
Subject: Re: [tsvwg] : Q: transport recommendations for "routing protocols"

Hi,

Lars

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 30 Jan 2016 07:58:12 -0800

> The CORE WG has discussed this, and the claim is that there is a class of devices at the very low end for which TCP will remain prohibitive. (Because even if the more capable devices become cheaper…

CORE WG did IMHO develop an end-to-end flattened/simplified transport +
session + presentation (arguably) stack with COAP. I think they drew
their decisions from different requirement than what i am looking for.

Or let me phrase it more succinctly: Once the IETF forces RPL(bis) to run
on top of CoAP, i am persuaded to use CoAP for this purpose.

> I don't think the footprint is much different.

Yepp. I am mostly worried about constrained devices intelligent enough to
allow/use one reliable transport, but then trying to save space by consttraing
it to ONLY one.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 30 Jan 2016 08:03:19 -0800

>  Lloyd Wood [email-masked] http://about.me/lloydwood 

In your opinion: How about SCTP compared to MPTCP ?

Of course, that does not answer the question if SCTP could be stripped
down to TCP size if one would only need TCP features - and even if possible,
when that would make sense.

I was guessing size is comparable when you compare same feature sets.

More so than code size, i wonder about memory required for connection
buffers. I have not looked into this for eternities, so i do not know
what options implementations today offer to dynamically tune connections
to minimum memory requirements (based on expected burst size etc..).
Pointers welcome.

Cheers
    Toerless