Subject: [tcpm] Tail loss probe talk [was Re: Draft agenda for IETF 87 in Berlin]

From: Yuchung Cheng <[email-masked]>
Date: Wed, 17 Jul 2013 08:48:35 -0700

On Wed, Jul 17, 2013 at 2:01 AM, Scharf, Michael (Michael)
<[email-masked]> wrote:
> Hi all,
>
> The first draft of the TCPM agenda can be found at https://datatracker.ietf.org/meeting/87/agenda/tcpm/ and is also copied below.
>
> We tried to take into account all requests, but as a result, the agenda is pretty full. This implies:
>
> - The slots are *total* time. Authors, please reserve 50% of your time for questions and discussion.
>
> - We got time slot requests for drafts that were not be updated since the last meeting, typically promising new results for the presentation in the meeting. Mailing list discussion in the next week would be *highly* welcome in order to justify a time slot on our full agenda.
Sure we should do that for TLP

>
> Please let us know if you have any comments, suggestions, or if we missed something.
>
> Happy agenda bashing!
>
> Michael, Pasi, Yoshifumi
>
>
>
> *************************************************************************************
>
> TCPM Agenda
> IETF 87 in Berlin, Germany
> Tuesday, July 30, 2013, 09:00-11:30
> ***********************************
>
> WG status
> ---------
>
> 09:00
> TCPM status
> Chairs
> 5min
>
>
> WG items
> --------
>
> 09:05
> draft-ietf-tcpm-1323bis-14
> Richard Scheffenegger
> 20min
>
> 09:25
> draft-ietf-tcpm-fastopen-04
> Jerry Chu / Yuchung Cheng
> 15mins
>
> 09:40
> draft-ietf-tcpm-newcwv-02
> Rafaello Secchi / Gorry Fairhurst
> 20min
>
> 10:00
> draft-ietf-tcpm-rtorestart-00 (no new draft)
> Anna Brunstrom
> 10min
>
> 10:10
> draft-ietf-tcpm-accecn-reqs-02
> Mirja Kuelewind
> 5min
>
>
> Non-WG items
> ------------
>
> 10:15
> draft-zimmermann-tcpm-tcp-rfc4614bis-02
> Alexander Zimmermann
> 10min
>
> 10:25
> draft-dukkipati-tcpm-tcp-loss-probe-01 (no new draft)
> Yuchung Cheng
> 10min
TCP Loss probe (TLP) is not updated the draft because we weren't sure
(yet) what to update, and the new data shows similar improvement that
we've presented
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//pubs/archive/41217.pdf

Based on the recent WG and private discussions and the SIGCOMM
reviews, people are not sure the performance improvement justifies
this new feature, as the loss recovery is feature rich and complicated
with RFC3517, RFC6937, RFC5682, RFC5827, etc.

To simplify, I'd like to present TLP as a simple conceptual change to
RTO recovery: On first timeout, retransmit the last packet instead of
the first unacked packet, and don't change but reduce first timeout to
2 SRTT, as a "quick loss probe".

As an alternative we've tried to only crank down the RTO but the
result is not good, because reducing cwnd to 1 is catastrophic, and
TCP today has to live sudden delay spikes due to buffer bloat and
mobile delays. It's better to be very conservative before declaring
the network is busted and use LW=1.

We are hopeful to get more WG interests for TLP :)

>
> 10:35
> draft-flach-tcpm-fec-00
> Tobias Flach
> 15min
>
> 10:50
> draft-gont-tcpm-tcp-seq-validation-00 (no new draft)
> Fernando Gont
> 10min
>
> 11:00
> draft-kuehlewind-tcpm-ecn-fallback-00
> draft-kuehlewind-tcpm-accurate-ecn-02
> Mirja Kuehlewind
> 15min
>
>
> If time permits
> ---------------
>
> Wired PRR effects
> Mirja Kuehlewind
> 5min
>
> Dealing with sequence-number randomizing firewalls
> Christoph Paasch
> 5min
>
> packetdrill: Scriptable Network Stack Testing, from Sockets to Packets
> Yuchung Cheng
> 5min
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Nandita Dukkipati <[email-masked]>
Date: Wed, 17 Jul 2013 10:54:14 -0700

> We are hopeful to get more WG interests for TLP :)

That's right, it would be great to have a simplified TLP adopted as WG
item. FWIW, if anyone would like to give the TLP algorithm a spin in their
tests, here are the two commits:

Basic TLP algorithm (Section 2 of
http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01)
Commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c

Detecting recovered losses in TLP (Section 3 of I-D)
Commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b717a8d245075ffb8e95a2dfb4ee97ce4747457

Nandita

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 25 Jul 2013 22:52:55 -0700

Hi Nantida, Yuchung,

Just out from my curiosity, I have a very minor question on the draft.
In the draft, 1-byte probing is somehow problematic to implement in
certain TCP stacks.
I'm wondering how it will be problematic.. Could you elaborate a bit?
--
Yoshifumi

On Wed, Jul 17, 2013 at 10:54 AM, Nandita Dukkipati <[email-masked]> wrote:
> That's right, it would be great to have a simplified TLP adopted as WG item.
> FWIW, if anyone would like to give the TLP algorithm a spin in their tests,
> here are the two commits:
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 29 Jul 2013 14:08:49 +0200

> I'm wondering how it will be problematic.. Could you elaborate a bit?
It refers more or less to our implementation experience in Linux,
which uses a packet-based CC. the problem is the original packet is
counted as 1, and now the 1-byte probe should be counted as 1/MSS
packet, or another 1 packet?
The solution was not trivial and was to now count the split the
original packet into 2 packets (MSS-1, 1 bytes). But this makes SACK
scoreboard accounting complicated and we always had some strange bugs,
therefore we ditched the approach.

But I agree the sentence is vague and needs to be removed or
clarified. Thanks for pointing that out.