Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
Sender: ray@liquibits.com
In-Reply-To: <kck14q$mjl$1@ger.gmane.org>
References: <CAAvW-fYH_n732uH4xEdQo_9RjHJM3Z4EiY-Bnu=_Drq37RgB8A@mail.gmail.com> <CAP7+vJ+Wop13D3qZ2Un6p1F-Oecjahc7dE2SgndtmcoOc1m5mg@mail.gmail.com> <kck14q$mjl$1@ger.gmane.org>
Date: Wed, 9 Jan 2013 12:04:41 -0800
Subject: Re: ANN: PyDTLS
From: rbit <py@liquibits.com>
To: Neal Becker <ndbecker2@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044306acabf0b304d2e0920e
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.336.1357761889.2939.python-list@python.org>
Lines: 126
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36515

--f46d044306acabf0b304d2e0920e
Content-Type: text/plain; charset=ISO-8859-1

Neal,

A network protocol that is unreliable (i.e., lacks retransmission of
dropped packets) and lacks congestion control will certainly never be a
common, general purpose protocol, due to the amount of work it imposes on
its user. Implementing an AIMD congestion control algorithm is burdensome
to an application, and only some use cases (like DNS) won't need congestion
control. Use of the Datagram Congestion Control Protocol is a potential way
out for applications, but DCCP (RFC 4340) isn't available on some common
platforms, like Windows.

That being said, if you find yourself in the kind of unique situation that
requires a network protocol with characteristics different from TCP (namely
prioritizing availability of data over its reliability), and you need
network security as well, then RFC 6347 is really the only reasonable game
in town over rolling your own solution.

The following are some of the main use cases that force applications into
datagram protocols:

    * Minimizing protocol overhead. TCP has relatively high overhead,
      for example, its 3-way handshake for connection establishment.
      One can see why DNS uses UDP.
    * Real-time data streaming. With this use case, it makes no sense
      to hold arrived data from the application, because prior packets are
      being recovered through retransmission. Such packets should just
      be forgotten about, especially if they fall within the margin of the
error
      concealment strategy of the application. Any sort of audio and/or
video
      transmission falls in this category. RTP is usually done over UDP (and
      is an illustrative use case for RFC 6347).
    * Anything that operates below the transport layer (layer 4 of the OSI
      model). Say you're writing a VPN at a virtual Ethernet level,
transmitting
      Ethernet frames among machines. In that case, protocols that either
      implement reliability (say, HTTP over TCP) or consciously try to avoid
      it (say, RTP over UDP) sit above you, and you would neither want to
      duplicate their reliability functions, nor introduce this unwanted
      behavior, respectively. But you may want security for your VPN.

I hope this helps.

Ray


On Wed, Jan 9, 2013 at 7:08 AM, Neal Becker <ndbecker2@gmail.com> wrote:

> A bit OT, but the widespread use of rfc 6347 could have a big impact on my
> work.
> I wonder if it's likely to see widespread use?  What are likely/possible
> use
> cases?
>
> Thank.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

--f46d044306acabf0b304d2e0920e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div><div><div><div><div><div><div>Neal,<br><br></div>A network prot=
ocol that is unreliable (i.e., lacks retransmission of dropped packets) and=
 lacks congestion control will certainly never be a common, general purpose=
 protocol, due to the amount of work it imposes on its user. Implementing a=
n AIMD congestion control algorithm is burdensome to an application, and on=
ly some use cases (like DNS) won&#39;t need congestion control. Use of the =
Datagram Congestion Control Protocol is a potential way out for application=
s, but DCCP (RFC 4340) isn&#39;t available on some common platforms, like W=
indows.<br>
<br></div>That being said, if you find yourself in the kind of unique situa=
tion that requires a network protocol with characteristics different from T=
CP (namely prioritizing availability of data over its reliability), and you=
 need network security as well, then RFC 6347 is really the only reasonable=
 game in town over rolling your own solution.<br>
<br></div>The following are some of the main use cases that force applicati=
ons into datagram protocols:<br><br></div>=A0=A0=A0 * Minimizing protocol o=
verhead. TCP has relatively high overhead,<br>=A0 =A0 =A0 for example, its =
3-way handshake for connection establishment.<br>
=A0 =A0 =A0 One can see why DNS uses UDP.<br></div></div>=A0=A0=A0 * Real-t=
ime data streaming. With this use case, it makes no sense<br></div>=A0=A0=
=A0=A0=A0 to hold arrived data from the application, because prior packets =
are<br></div>=A0=A0=A0=A0=A0 being recovered through retransmission. Such p=
ackets should just<br>
</div>=A0=A0=A0=A0=A0 be forgotten about, especially if they fall within th=
e margin of the error<br></div>=A0=A0=A0=A0=A0 concealment strategy of the =
application. Any sort of audio and/or video<br></div>=A0=A0=A0=A0=A0 transm=
ission falls in this category. RTP is usually done over UDP (and<br>
</div>=A0=A0=A0=A0=A0 is an illustrative use case for RFC 6347).<br></div>=
=A0=A0=A0 * Anything that operates below the transport layer (layer 4 of th=
e OSI<br></div>=A0=A0=A0=A0=A0 model). Say you&#39;re writing a VPN at a vi=
rtual Ethernet level, transmitting<br>
</div>=A0=A0=A0=A0=A0 Ethernet frames among machines. In that case, protoco=
ls that either<br></div>=A0=A0=A0=A0=A0 implement reliability (say, HTTP ov=
er TCP) or consciously try to avoid<br></div>=A0=A0=A0=A0=A0 it (say, RTP o=
ver UDP) sit above you, and you would neither want to<br>
</div>=A0=A0=A0=A0=A0 duplicate their reliability functions, nor introduce =
this unwanted<br></div>=A0=A0=A0=A0=A0 behavior, respectively. But you may =
want security for your VPN.<br><br></div>I hope this helps.<br><br>Ray<br><=
div class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Wed, Jan 9, 2013 at 7:08 AM, Neal Bec=
ker <span dir=3D"ltr">&lt;<a href=3D"mailto:ndbecker2@gmail.com" target=3D"=
_blank">ndbecker2@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
A bit OT, but the widespread use of rfc 6347 could have a big impact on my =
work.<br>
I wonder if it&#39;s likely to see widespread use? =A0What are likely/possi=
ble use<br>
cases?<br>
<br>
Thank.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<a href=3D"http://mail.python.org/mailman/listinfo/python-list" target=3D"_=
blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br></div></div>

--f46d044306acabf0b304d2e0920e--