Re: [re-ECN] Other transports than TCP in charter

[Bob Briscoe <[e-mail]>]

Bo, Ingemar,

I want to manage expectations here.

ConEx is ambitious, because it tries to shoe-horn something radically different into the interoperability layer (IP) that everything else builds over or under. During the design of re-ECN, every time we realised there was a new constraint (e.g. a security attack), it often took weeks to find a new design that still met all the other constraints. [We should document all the design constraints - I'm v willing to help with that.]

The degrees of freedom are really minimal down in IP. You have to seek out each little crack, but then you can't just pop the protocol in. You have to knock it in hard with a heavy hammer.

So far the number of minds working on this has been small: my team plus a number of researchers devising attacks on the protocol. Once that number grows, more constraints may well be found. I sincerely promise we have tried to find them all, but... a lethal constraint might arise.

Therefore I believe we should charter to:
a) specify the base ConEx protocol in IP
b) provide design guidance for any ConEx transport
   (including with no feedback at all*).
c) specify a ConEx transport extension for TCP
d) specify a minimum of n other transport extensions in detail, where n=0

[* = If we adopt re-ECN, there are already guidelines in draft-briscoe-tsvwg-re-ecn S.6.2.1 on how to do re-ECN with no feedback at all (ie. pure UDP in datagram mode) or very infrequent feedback. This is important, because we have to support re-ECN under transports like
* digital fountain, which uses FEC and no feedback.
* or DNS over UDP. 
* I have also already specified a form of re-ECN for an inelastic transport (see ref to re-PCN in S.6.2.2).]

Once we've written a full spec for TCP and we've covered pure UDP (as a design guideline in the spec for ConEx in IP), this means we've covered the transports that are the "host requirements" for the Internet.

I think n=0 makes sense for the charter, in case we come across a big problem and have to stop at the first hurdle. This doesn't stop us doing more transports within the w-g; we just don't charter to *have* to do them.

There is an argument for n=1: ie. we specify TCP and one example from another extreme of the design space. That would give comfort that ConEx is extensible. I wouldn't argue against n=1, but I'd prefer us to try to do TCP first.

If we decided n=1, I would suggest ConEx in RTP/RTCP over UDP first, but only for unicast.



Bob

BTW, I tried to show the transport design space over re-ECN in my talk to ICCRG in Stockholm in Jul'09. See slide 19 of <http://bobbriscoe.net/presents/0907ietf/#0907iccrg" rel="nofollow"> http://bobbriscoe.net/presents/0907ietf/#0907iccrg>. Apologies, I omitted LEDBAT from that slide.


At 02:09 13/11/2009, bo zhou wrote:

I believe Ingemar's suggestion is reasonable.
Hope the ConEx WG can consider all transport protocols rather than TCP only.
 
Regards,
 
Bo Zhou
China Mobile

On Fri, Nov 13, 2009 at 10:00 AM, Ingemar Johansson S < [e-mail]> wrote:

Hi

I have raised this concern earlier on this list but I do this again just to make sure that this does not fall between the chairs.

The proposed "strawman" BoF charter discusses TCP. I would like the group to consider IP as the common denominator, the motivation can be found at.

http://www.ietf.org/mail-archive/web/re-ecn/current/msg00410.html" rel="nofollow"> http://www.ietf.org/mail-archive/web/re-ecn/current/msg00410.html

In short the work done in ConEx should be able to apply on UDP as well as TCP. Other transports of interest may be SCTP and DCCP.

/Ingemar

=================================

INGEMAR JOHANSSON  M.Sc.

Senior Research Engineer

Ericsson AB

Multimedia Technologies

Labratoriegränd 11

971 28, Luleå, Sweden

Phone [phone]

SMS/MMS [phone]

[e-mail]

http://www.ericsson.com/" rel="nofollow"> www.ericsson.com

Visit http://labs.ericsson.com/" rel="nofollow">http://labs.ericsson.com !

=================================

_______________________________________________

re-ECN mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/re-ecn" rel="nofollow"> https://www.ietf.org/mailman/listinfo/re-ecn

--
Regards,

Bo Zhou
China Mobile
_______________________________________________
re-ECN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/re-ecn" rel="nofollow"> https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design