Re: [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Wesley Eddy]

Hi, Dave, strangely it looks like nobody has been copying TSVWG on this 
thread, even though that is where the L4S work is happening in the IETF!  :)


I just wanted to respond to one part of your message since I am 
currently acting as document shepherd for the L4S drafts in TSVWG, and 
it seems like maybe you don't know where to find all of the IETF 
materials in order to participate (based on the "stalled out 
indefinitely" comment below).  So in case it's helpful here are some 
pointers to where things are kept.


The 3 base L4S documents were adopted in the TSVWG WG, and have been 
regularly updated.  You can find the charter and milestone dates 
(currently June 2019) quite easily on the WG datatracker page: 
https://datatracker.ietf.org/group/tsvwg/about/ and of course the 
"Documents" tab there takes you to the copies of all the documents.


There have been updates on L4S and presentations/discussions at the IETF 
meetings (with minutes and charts posted to the proceedings), as well as 
L4S draft reviews and comment threads on the TSVWG list whose archives 
are under "List archive".  You can find meeting minutes and slide decks 
also readily linked from that WG page: 
https://datatracker.ietf.org/group/tsvwg/meetings/


There are source code repositories, papers, videos, etc. that the 
proponents have also made very easy to find, e.g. 
https://riteproject.eu/dctth/#code (and as linked in meeting materials).


Since we (TSVWG chairs) are looking for inputs towards WGLC readiness to 
proceed on these, hopefully this information is helpful for you.



On 3/15/2019 6:46 AM, Dave Taht wrote:
> ...
>
> Some background to this: after the L4S/TCP Prague/and dualpi 
experiments appeared stalled out indefinitely in the IETF, and with our 
own frustration with IETF processes, bufferbloat.net project members 
publicly formed our own working group to look into the problems with 
ecn, back in august of last year.


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fixing bufferbloat in 2017

[Wesley Eddy]

On 11/28/2016 10:12 AM, Dave Taht wrote:

On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brown  wrote:

A short RFC with a clear summary would change the ground on which we stand.
Include me in if you're planning one.

Call me grumpy. Call me disaffected. But it's been 4 years into the
IETF RFC process with codel and fq_codel with still no end in sight.




Hi Dave, while it's been undeniably slow, "no end in sight" is not 
really accurate.  Here is the correct status, since I am document 
shepherd for both:


- The fq-codel draft is completely and totally done in terms of IETF 
process, and has been in the RFC Editor's queue simply awaiting the 
codel draft to arrive.  This is what the "MISSREF" state indicates in 
that IETF datatracker tool.  It completed the IETF last call and IESG 
balloting in March/April earlier this year.


- The codel document completed AQM working group last call, and I 
believe is awaiting the authors to make changes requested by the Area 
Director in order to go for IETF Last Call and IESG balloting.


The end is most definitely within sight!


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] some good bloat related stuff on the ICCRG agenda, IETF #86 Tuesday, March 12 2013, 13:00-15:00, room Caribbean 6

[Wesley Eddy]

On 2/28/2013 10:53 AM, Dave Taht wrote:
 
 For those that don't attend ietf meetings in person, there is usually
 live audio and jabber chat hooked up into the presentations.
 
 See y'all there, next month, in one form or another.
 


In the TSVAREA meeting, we've also set aside some time to talk
about AQM and whether there's interest and energy to do some
more specific work on AQM algs in the IETF (e.g. like CoDel and
PIE):

https://datatracker.ietf.org/meeting/86/agenda/tsvarea

I'm working with Martin on some slides to seed the discussion,
but we hope that it's mostly the community that we hear from,
following up in the higher-bandwidth face-to-face time from
the thread we had on the tsv-a...@ietf.org mailing list a few
months ago.


-- 
Wes Eddy
MTI Systems
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Codel] RFC: Realtime Response Under Load (rrul) test specification

[Wesley Eddy]

On 11/6/2012 8:56 AM, Dave Taht wrote:
 On Tue, Nov 6, 2012 at 2:42 PM, Henrique de Moraes Holschuh
 h...@hmh.eng.br wrote:
 On Tue, 06 Nov 2012, Dave Taht wrote:
 I have been working on developing a specification for testing networks
 more effectively for various side effects of bufferbloat, notably
 gaming and voip performance, and especially web performance as
 well as a few other things that concerned me, such as IPv6 behavior,
 and the effects of packet classification.

 When it is reasonably complete, it would be nice to have it as an
 informational or better yet, standards-track IETF RFC.

 IETF RFC non-experimental status allows us to require RRUL testing prior to
 service acceptance, and even add it as one of the SLA metrics on public
 tenders, which goes a long way into pushing anything into more widespread
 usage.
 
 It was my intent to write this as a real, standards track rfc, and
 also submit it as a prospective test to the ITU and other testing
 bodies such as nist, undewriter labratories, consumer reports, and so
 on.
 
 However I:
 
 A) got intimidated by the prospect of dealing with the rfc editor
 
 B) Have some sticky problems with two aspects of the test methodology
 (and that's just what I know about) which I am prototyping around.
 Running the prototype tests on various real networks has had very
 interesting results... (I do hope others try the prototype tests,
 too, on their networks)
 
 C) thought it would be clearer to write the shortest document possible
 on this go-round.
 D) Am not particularly fond of the rrule name. (suggestions?)
 
 I now plan (after feedback) to produce and submit this as a standards
 track RFC in the march timeframe.
 
 It would give me great joy to have this test series included in
 various SLA metrics, in the long run.
 


Hi Dave, in my role as IETF TSV AD, I would be happy to help
you get this into the IETF.  Please note that you can't get
a Standards Track RFC published without a working group
adopting it or an AD sponsoring it.

This topic would be of interest for the IPPM and BMWG working
groups, and I know it is of interest to me as a TSV AD, so we
should be able to find a way to bring it in.

In fact, the timing is good, as FCC folks are at the IETF this
week talking about their vision for broadband test and
measurement architecture, and these tests may relate nicely
to that proposed work.

-- 
Wes Eddy
MTI Systems
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?

[Wesley Eddy]

On 3/20/2011 9:28 PM, da...@lang.hm wrote:

On Mon, 21 Mar 2011, Jonathan Morton wrote:


On 21 Mar, 2011, at 12:18 am, da...@lang.hm wrote:


0) Buffering more than 1 second of data is always unacceptable.


what about satellite links? my understanding is that the four round
trips to geosync orbit (request up, down, reply up down) result in
approximatly 1 sec round trip.


That is true, but it doesn't require more than a full second of
buffering, just lots of FEC to avoid packet loss on the link. At those
timescales, you want the flow to look smooth, not bursty. Bursty is
normal at 100ms timescales.

What I've heard is that most consumer satellite links use split-TCP
anyway (proxy boxes at each end) thus relieving the Internet at large
from coping with an unusual problem. However, it also seems likely
that backbone satellite links exist which do not use this technique. I
heard something about South America, maybe?


I've heard that they do proxy boxes at each end for common protocols
like HTTP, but they can't do so for other protocols (think ssh for example)


Anyway, with a 1-second RTT, the formula comes out to max 1 second of
buffering because of the clamping.


and what if you have a 1 second satellite link plus 'normal internet
latency', or worse, both ends are on a satellite link, giving you a
2-second+ round trip time?

if you don't have large enough buffers to handle this, what happens?




Propagation delay to a geosynchronous relay is ~125 ms.  Round-trip 
propagation delay contributes ~500 ms, so it isn't quite as bad as you 
think, though still long.


Many tricks are played with accelerator gateways to improve bulk 
transfer throughput for TCP users (see e.g. RFC 3135).


There may be a challenge in debloating the devices that support such 
links, as their buffers and the functions they serve optimize other 
metrics (e.g. low packet loss rate, bulk transfer throughput, etc.).


--
Wes Eddy
MTI Systems
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat