Re: [dtn-interest] FW: Results of IETF-conflict review for draft-irtf-dtnrg-tcp-clayer-08

[<[e-mail]>]

With newReno, only SACK matters now. (Though window scaling is still
a dark art, with little thanks to Windows XP.)

As it happens, I've spent the last couple of years dealing with PEP middlebox TCP
accelerators and caches for satellite links.

When supporting a number of ISPs backhauled via satellite links from the island
populations they themselves support, there are interesting scalability problems
with tracking the number of flows and resulting buffer state held over long
periods of time. It's interesting pushing the state of the art there.

The main difference between these 'transparent' proxies and a more explicit,
visible, hop-by-hop partitioning in the different domain conditions afforded by
bundling (or tuned visible http proxy caching) is that these get -used-.

Endpoints are dumb. Endpoints do dumb things. State at endpoints can't
be trusted. That TCP has congestion control and is trusted to control its
own state is increasingly an anomaly in a world where every link must have
protection against DoS attacks. TCP can't be trusted to do the right thing
through bottlenecks like satellite links.

While state in the network is undesirable, with PEPs, NAT and firewalls
(never mind QoS shaping or BGP) it's necessary - and it's state under the
explicit control of a (hopefully knowledgeable) network operator. The
'impedance mismatch' of capacity, speed and delay between the satellite
and terrestrial networks imposes QoS shaping, acceleration...it's not
something that can be resolved by itself.

In discussing whether the junction between the satellite and ground
network is a proxy, a bundling agent, or something else, we accept
that there must be some sort of stateful control there. We're
only debating what exact form that state takes.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Caini Carlo [[e-mail]]
Sent: 25 February 2014 10:30
To: Vint Cerf; Wood L  Dr (Electronic Eng)
Cc: dtn-interest
Subject: Re: [dtn-interest] FW: Results of IETF-conflict review for  draft-irtf-dtnrg-tcp-clayer-08

Dear Vint and Lloyd,
     In my opinion, the possibility of using TCP
as convergence layer in a Bundle Protocol DTN
architecture has many advantages that go beyond
the mere compatibility with Internet and that can
be achieved (in some selected but important
cases) despite the challenges of the links.
To cite an example I have personally
investigated, consider GEO satellite
communications. In these the main challenge is
the RTT of about 600 ms mainly due to the
propagation time on the satellite link. With such
a large RTT, TCP New Reno cannot provide
satisfactory performance, especially in the
presence of concurrent terrestrial TCP traffic
(i.e. with short RTTs). The usual solutions are
TCP splitting PEPs that divide the end-to-end
paths into three legs: 1) from source to the
first PEP, 2) between the two PEPs, 3) from PEP
to destination. TCP splitting PEPs provide good
performance but violate the end-to-end semantic
of TCP and are ineffective with IPsec.
By contrast, the BP DTN architecture allows to
"naturally" split the end-to-end connection into
3 DTN hops (the same as before), which
automatically solves the problem of RTT
unfairness between satellite and terrestrial
connection; you can use TCP and the first and the
last, as they have no challenges at all; you can
use whatever convergence layer you want in the
intermediate connection (the satellite one),
included TCP variants specialized for satellite.
Note that on a link with less than 600ms and
without (or with just minor disruption) these
specialized variants of TCP work well (i.e. you
do not need LTP). In short, in GEO communications
you can have TCP, by choice, on all the DTN hops,
with excellent performance. The price to pay with
respect to PEPs is the lack of transparency,
because you you need to install and use DTN on
the end points. It may be worthwhile.

Yours,
    Carlo






At 10.43 25/02/2014, Vint Cerf wrote:
>there is a lot more TCP and IP network readily
>available than others so, statistically, this is
>not a surprise. I anticipate that LTE may prove
>another supporting environment. Of course, there
>continues to be work in deep space such as the
>latest laser comm tests to/from the moon at 600 Mb/s.
>
>vint
>
>
>
>On Tue, Feb 25, 2014 at 4:27 AM,
><<mailto:[e-mail]>[e-mail]> wrote:
>Vint,
>
>the impression I've gained is that most bundle
>protocol use is over TCP - that is,
>rather than being a compatibility mechanism, TCP
>is the dominant transport for the
>bundle protocol.
>
>Are there any statistics or metrics of use that can shed light here?
>
>thanks
>
>Lloyd Wood
><http://about.me/lloydwood>http://about.me/lloydwood
>________________________________________
>From: Vint Cerf [<mailto:[e-mail]>[e-mail]]
>Sent: 25 February 2014 08:51
>To: Wood L Â Dr (Electronic Eng)
>Cc: dtn-interest
>Subject: Re: [dtn-interest] FW: Results of
>IETF-conflict review for draft-irtf-dtnrg-tcp-clayer-08
>
>Lloyd,
>This makes it possible to support applications
>end to end over DTN including the Internet.
>It is a compatibility mechanism.
>
>vint
>
>
>
>On Tue, Feb 25, 2014 at 3:23 AM,
><<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>>
>wrote:
>Congratulations to  DTNRG on reaching the below milestone in getting
>this draft well on the way to being published.
>
>It's been a long delay since draft-demmer-dtnrg-tcp-clayer-00.txt in October
>2006, but defining how the bundle protocol is carried over TCP will go a long
>way to improving support for networked communications under the very
>difficult disrupted and delay-tolerant network conditions when TCP break...
>um. Ah.
>
>Lloyd Wood
><http://about.me/lloydwood>http://about.me/lloydwood
>________________________________________
>From: IETF-Announce
>[<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>]
>On Behalf Of The IESG
>[<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>]
>Sent: 24 February 2014 17:40
>To: Lars Eggert;
><mailto:[e-mail]>[e-mail]<mailto:[e-mail]>;
><mailto:[e-mail]>[e-mail]<mailto:[e-mail]>
>Cc:
><mailto:[e-mail]>[e-mail]<mailto:[e-mail]>;
>The IESG;
><mailto:[e-mail]>[e-mail]<mailto:[e-mail]>
>Subject: Results of IETF-conflict review for draft-irtf-dtnrg-tcp-clayer-08
>
>The IESG has completed a review of draft-irtf-dtnrg-tcp-clayer-08
>consistent with RFC5742.
>
>
>The IESG has no problem with the publication of 'Delay Tolerant
>Networking TCP Convergence Layer Protocol'
><draft-irtf-dtnrg-tcp-clayer-08.txt> as an Experimental RFC.
>
>
>The IESG has concluded that there is no conflict between this document
>and IETF work.
>
>
>
>The IESG would also like the IRTF to review the comments in the
>datatracker related to this document and determine whether or not they
>merit incorporation into the document. Comments may exist in both the
>ballot and the history log.
>
>The IESG review is documented at:
><http://datatracker.ietf.org/doc/conflict-review-irtf-dtnrg-tcp-clayer/>http://datatracker.ietf.org/doc/conflict-review-irtf-dtnrg-tcp-clayer/
>
>A URL of the reviewed Internet Draft is:
><http://datatracker.ietf.org/doc/draft-irtf-dtnrg-tcp-clayer/>http://datatracker.ietf.org/doc/draft-irtf-dtnrg-tcp-clayer/
>
>The process for such documents is described in RFC 5743
>
>Thank you,
>
>The IESG Secretary
>
>
>_______________________________________________
>dtn-interest mailing list
><mailto:[e-mail]>[e-mail]<mailto:[e-mail]>
><https://www.irtf.org/mailman/listinfo/dtn-interest>https://www.irtf.org/mailman/listinfo/dtn-interest
>
>
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/dtn-interest