>
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
Michael,
Yes, I should have said that the most useful aspect of your paper is the
model that ties all the different algos together allowing comparison.
Bob
On 25/05/17 08:55, Michael Menth wrote:
Hi Bob, hi Rong,
Am 25.05.2017 um 00:34 schrieb Bob Briscoe:
Michael,
I just started
1.03
121.02
131.02
141.01
151.01
161.01
171.01
181.00
191.00
201.00
Cheers
Bob
On 30/03/17 10:57, Michael Menth wrote:
Hi all,
Am 30.03.2017 um 11:08 schrieb Jonathan Morton:
On 30 Mar, 201
ching logic for that. If your underlying algorithm is sound,
it will naturally decay to zero packet drops if the empty-queue condition
persists.
- Jonathan Morton
--
____________
Bob Briscoe
Rong Pan mailto:ro...@cisco.com>>, Luca
Muscariello <mailto:luca.muscarie...@gmail.com>>, "Bless, Roland (TM)"
mailto:roland.bl...@kit.edu>>
Cc: tsvwg IETF list mailto:ts...@ietf.org>>, Fred
Baker mailto:fredbaker.i...@gmail.com>>,
Bob Briscoe mailto:
Rong,
Some comments inline. And one remaining question at the end...
On 28/03/17 02:04, Rong Pan (ropan) wrote:
Bob,
Sorry for the late reply. I have been traveling. Please see inlineŠ
Rong
On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" wrote:
Rong, Preethi, Greg, Fred,
Rong, Preethi, Greg, Fred, and others involved in PIE,
You may recall that when we wrote PI2 we didn't include any of PIE's
heuristics. Mostly because PI2 solved the issues they addressed
intrinsically. But we left some until we had checked their benefit,
which is what I'm doing now...
My fi
Roland,
On 24/11/16 20:48, Bless, Roland (TM) wrote:
Hi Bob,
see comments inline, please.
Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
I share your concern about cc-specific AQMs. But that is not a good
characterization of what we're doing.
Yep, but it's part of what you're
Mario,
On 24/11/16 16:57, Mario Hock wrote:
Hello Bob and Roland,
I followed your discussion and want to share my opinion, here.
(Comments inline).
Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
*Is any AQM CC-neutral?**
*Note rule 5 <https://tools.ietf.org/html/rfc7567#section-4.5>
Jonathan,
On 22/11/16 20:37, Jonathan Morton wrote:
On 22 Nov, 2016, at 21:09, Bob Briscoe wrote:
{Note 1} I have never got a good answer to my questions on aqm@ietf as to why a
sqrt that controls the shrinkage of the spacing between dropped packets has
something to do with the steady state
Indeed, at the moment, when DCTCP is on its own in the L4S
queue of the DualQ AQM as coded now, it hits up against a step
threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just
because we didn't want to change too much about DCTCP at one time. But
it's also got some
thms solve the
problem (in plain English and maths), how the Dual Queue Coupled AQM
algorithm works, and recording the results of extensive testbed
experiments.
“`/*Data Centre to the Home’: Ultra-Low Latency for All*/
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.
helps search
engines find it when people look for aqm-dualq-coupled?
Makes sense?
Bob
--
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
doption activities.
Bob
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
__
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
topics will be useful to hear on the mailing list and
in Berlin.
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
________
Bob Briscoe http://bobbriscoe.net/
Volunteers pls: L4S non-WG-forming BoF proposal cut-off
approaching
Date: Wed, 18 May 2016 12:47:26 +0100
From: Bob Briscoe
To: TCP Prague List
Folks,
At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in
Buenos Aires, there was support for a BoF about L4S, In the
:44, Bob Briscoe wrote:
Folks,
Reminder, agenda & supporting materials below for the Bar BoF on L4S /
DualQ Coupled AQM / TCP Prague
*Event details**
*Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B
*Supporting materials / background:**
*h
9:55 end
Most time will be allowed for people to talk from the floor.
Cheers
Bob & Koen
On 05/04/16 13:02, Bob Briscoe wrote:
Folks,
We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B
We have the regular IETF remot
016 at 12:21 PM, Spencer Dawkins at IETF
mailto:spencerdawkins.i...@gmail.com>>
wrote:
Just to try to be helpful ...
On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe mailto:i...@bobbriscoe.net>> wrote:
John,
On 19/02/16 18:23, John Leslie wrote:
Bo
On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe mailto:i...@bobbriscoe.net>> wrote:
John,
On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe mailto:i...@bobbriscoe.net>> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs a
Jonathan,
It does make sense.
Inline...
On 24/03/16 20:08, Jonathan Morton wrote:
On 21 Mar, 2016, at 20:04, Bob Briscoe wrote:
The experience that led me to understand this problem was when a bunch of colleagues
tried to set up a start-up (a few years ago now) to sell a range of "equi
de deployable, with more people trying them, we're not
going to get anywhere. There's still billions of boxes left to deploy
and a long tail of deployed gear that will probably last 10 years or
more.
--
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
Cheers
Bob
[Hohlfeld14] Hohlfeld, O., Pujol, E., Ciucu, F., Feldmann, A. & Barford,
P., "A QoE Perspective on Sizing Network Buffers," In: Proc. Internet
Measurement Conf (IMC'14) pp.333-346 ACM (November 2014)
-Toke
--
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
IESG, authors,
1. Safe?
My main concern is with applicability. In particular, the sentence in
section 7 on Deployment Status: "We believe it to be a safe default and
encourage people running Linux to turn it on: ...". and a similar
sentiment repeated in the conclusions. "and we believe it to
John,
On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.
We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
This fee
et...
If you missed all the above, we've pulled together videos of demos,
short papers, I-Ds etc here: https://riteproject.eu/dctth/
Incuding this particularly useful 2-pager: “Ultra-Low Delay for All
<http://www.internetsociety.org/publications/ietf-journal-november-2015/ultra-low-delay-for-a
: Koen De Schepper , Ing-jyh
Tsang , Bob Briscoe
, ing-jyh.ts...@alcatel-lucent.com
A new version of I-D, draft-briscoe-tsvwg-ecn-l4s-id-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.
Name: draft-briscoe-tsvwg-ecn-l4s-id
Revision:
up, we can't tell for sure.
Bob
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--
Bob Briscoe http://
y & Van back in 2013 that started this thread
and still hasn't been answered.
Cheers
Bob
Does this make any sense?
Regards,
Polina
On 09/30/2015 02:59 PM, Bob Briscoe wrote:
Polina,
I think this was it:
<https://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.pdf>
I have a se
Mikael,
I'll try to explain better how I'm hoping to use DSCP temporarily
without needing to solve the Diffserv interconnect problem...
On 06/08/15 21:38, Mikael Abrahamsson wrote:
On Tue, 4 Aug 2015, Bob Briscoe wrote:
*Combining ECT(0) and CE with a globally assigned DSCP sol
Also below I've restated a couple of points I made back in 2013 when I
first posted this.
On 12/11/13 22:30, Bob Briscoe wrote:
5/ My analysis also shows that the rate of increase in drop probablity
is inversely proportional to the link rate. I don't believe this is
desirable, as it
mailman/listinfo/aqm
--
________
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
tsman wrote:
Dear Bob,
On 09/30/2015 10:50 AM, Bob Briscoe wrote:
Early on, Rong Pan showed that it takes CoDel ages to bring high load
under control. I think this linear increase is the reason.
Is there a link to this ?
Polina
___
aqm mailing list
a
It was surprising to me at least, so
I thought I'd share my findings, in the hope that someone would either
find them useful or tell me how they're wrong (or both!). :)
-Toke
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/l
Yuchung,
On 08/08/15 00:54, Yuchung Cheng wrote:
On Fri, Aug 7, 2015 at 7:46 AM, Bob Briscoe wrote:
AQM Chairs, list,
My co-authors and I have just posted a draft spec of the DualQ Coupled AQM we presented
and demonstrated in Prague under the title "Data Centre to the Home&
than it would have if there had been just one
FIFO.
Cheers
Bob, Koen, Olga & Inton.
Forwarded Message
Subject: New Version Notification for
draft-briscoe-aqm-dualq-coupled-00.txt
Date: Fri, 07 Aug 2015 06:41:15 -0700
From: internet-dra...@ietf.org
To: Koen De Sc
Gorry,
On 06/08/15 09:56, Gorry Fairhurst wrote:
A few comments in-line, as someone interested in taking things forward:
On 04/08/2015 13:42, Bob Briscoe wrote:
John,
[Ignore previous - clicked 'send' too early]
There was much discussion about this identifier issue in Prague. Ma
John,
[Ignore previous - clicked 'send' too early]
There was much discussion about this identifier issue in Prague. Many
people are well-aware that the sticking point is availability of an
identifier, and its associated politics.
On 04/08/15 05:08, John Leslie wrote:
Bob Bris
John,
There was much discussion about this identifier issue in Prague. Many
people are well-aware that the sticking point is availability of an
identifier, and its associated politics.
On 04/08/15 05:08, John Leslie wrote:
Bob Briscoe wrote:
I do not believe an IP (v4) option or a v6
t does,
which need to be resolved before we could even consider Standards Track.
At first blush, this looks like a good match for Experimental use of
ECT(1).
--
John Leslie
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinf
below.
And below that, is the original announcement with some context and
background URLs.
You can catch up on any discussion you've missed using the list archives
via the link above.
If you want to respond about something most relevant to tcpprague, pls
avoid cross-posting to
dvance.
Cheers
Bob
--
____________
Bob Briscoe http://bobbriscoe.net/
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
ow is to go idle (even momentarily) then perhaps it was because
target is too small. Using some rule you could increase target.
Conversely you can heuristically identify when target is likely too
large, and reduce it.
Simon
On 7/3/2015 5:20 AM, Bob Briscoe wrote:
AQM chairs and list,
1) Delay
set the config too.
Writing this all down cleared up a lot of nagging doubts I had in my
mind. I hope it helps others too.
Bob
PS. Note my new interim email @.
--
________
Bob Briscoe http://bobbrisc
and
improvements to the slow-start algorithm (e.g. HSS).
Bob
PS. Pls note my new interim email @.
Sorry for extended delay replying - your mail arrived after I left my
office for the last time (I've left BT).
I'm still "between jobs", but I'm trying to catch up on unf
ou could build PIE on top of the parts of RED implemented in
hardware (but this statement might not be true for all vendors'
implementations).
Bob
-Vishal
--
http://www.cs.columbia.edu/~misra/ <http://www.cs.columbia.edu/%7Emisra/>
On May 22, 2015, at 9:38 AM, Bob Briscoe <mailto
ing up. Let me
just comment on the following thread. I will
spend more time on Bob's detailed comments and
give feedback later. For now, please see inline
>
Thanks,
Rong
From: Greg White <<mailto:g.wh...@cablelabs.com>g.wh...@cablelabs.com>
Date: Wednesday, May 13, 2015 10
en the mins came close to the target in
recent time (e.g. by an EWMA), then the more
likely it would drop. GIven no magic number will
be correct, it's better to use a continuous
approach, rather than when you're one side of a
threshold you're fine and the other you're dea
f expected RTTs.
The former might be 100ms, but the latter is more likely to be
15-20ms, given most traffic in the developed world these days comes
from CDNs. This could make significant difference to performance.
Bob
Date: Tue, 14 Apr 2015 19:59:47 +0100
To: "Fred Baker (fred)"
the times it knows drops will occur). But it's a
lot easier to just send faster by ignoring drop signals anyway.
CoDel's determinism might become problematic if
unresponsiveness to congestion became a serious
problem, so that it became necessary to police c
re not in the header block.
* About half ought to be made to depend on other constants
* Need to state how to set the remaining constants for
different environments
* Implementation suggestion for Autotuning alpha & beta
Bob
_
ts/JqxCe2pFr67
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
Bob Briscoe, BT
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
the IETF want to standardise
it? Is the intention that AQM-chair will be a job for life?
Bob
________
Bob Briscoe, BT
___
aqm mailing list
a
David,
At 22:46 13/04/2015, David Lang wrote:
On Mon, 13 Apr 2015, Bob Briscoe wrote:
David,
Returning from a fortnight offlist...
I think your conception of how ECN works is incorrect. You describe
ECN as if the AQM marks one packet when it drops another packet.
You say that the ECN-mark
teresing to provide soem way for the application
sending the traffic to detect dropped packets and ECN responses. For
example, a streaming media source (especially an interactive one
like video conferencing) could adjust the bitrate that it's sending.
David Lang
___
ssumption "as long as the flow
rate is small relative to the link capacity", which might not be
applicable in your deployment scenario. However, it might be worth
you taking a look.
Bob
_________
to hide losses, I guess it is a good example
to consider whether ECN still offers sufficient benefits over and
above just removing losses.
Cheers
Bob
--
John Leslie
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
___
thing
about any of the specifics in this para in the AQM draft.
> Bob
+GF: Im also considering replacing /congestive collapse/ by /congestion
collapse/ which seems a more common term, as noted by John L.
Works for me.
Regards
Bob
__
diff are available at
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > aqm mailing list
> > aqm@ietf.org
> > http
Dave,
At 21:25 15/05/2014, Dave Taht wrote:
On Thu, May 15, 2014 at 9:17 AM, Bob Briscoe wrote:
> Gorry,
>
>
> At 16:55 15/05/2014, go...@erg.abdn.ac.uk wrote:
>>
>> Great, I look forward to comments on the actual text. I agree the front
>> part needs more struct
ors did not
start this... the document we update uses this language and I think in
the update it needs to be confined to the early sections, possibly with
your text on why there is not mention elsewhere.
We look forward to the detailed comments.
Gorry
_
's only, but allow me one nit about the Intro:
>
> " there is currently no consensus solution to controlling the
> congestion caused by such aggressive flows; significant research and
> engineering will be required before any solution will be available.
> It is i
ity of the Internet.
"
The draft could at least mention congestion policing and ConEx RFCs
coming out of the IETF right now (e.g. RFC6789 and
draft-ietf-conex-abstract-mech, which is with the IESG).
I promise I'll do a proper detailed review of the new text ASAP.
Bob
At 13:13 15/05/2
s at least some of the
points made.
--
Wes Eddy
MTI Systems
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
Bob Briscoe,
t out in the AQM Guidance,
probably under:
"4.5. AQM algorithms SHOULD NOT be dependent on specific transport
protocol behaviours"
which currenty has only one example: "don't assume TCP".
Bob
Date: Thu, 23 Jan 2014 14:51:25 +
To: Ingemar Johansson S
From: Bob Bris
Ingemar, inline...
At 06:36 22/01/2014, Ingemar Johansson S wrote:
Hi
Please find answers inline
/Ingemar
> -Original Message-
> From: Bob Briscoe [mailto:bob.bris...@bt.com]
> Sent: den 21 januari 2014 23:50
> To: Ingemar Johansson S; ruediger.g...@telekom.de
> Cc:
expertise is too
> limited to judge details).
>
> Regards,
>
> Ruediger
>
> -Ursprüngliche Nachricht-
> Von: tsvwg-boun...@ietf.org [mailto:tsvwg-boun...@ietf.org] Im Auftrag
> von Bob Briscoe
> Gesendet: Montag, 4. November 2013 23:04
> An: tsvwg IETF list; AQM IETF list
>
he network, but not so large as to materially increase measured
latency or probability of loss. At the point that it sends data in a
manner that creates a sustained queue, it has exceeded what would be
considered a useful burst size.
Bob Briscoe, BT
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
If you can make red work
on wifi, I would love to know how. My take on this list was that we
were trying to standardize on some aqm technologies that exist and are
being deployed today. Bus is leaving the station.
On Thu, Dec 12, 2013 at 4:05 PM, Bob Briscoe wrote:
> Dave,
>
>
> At 22:11
n Datacenters via Local Link Balancing
http://www.irt-systemx.fr/wp-content/uploads/2013/12/AINTEC.ppt
Sigh. I'll
On Thu, Dec 12, 2013 at 11:35 AM, Jim Gettys wrote:
>
>
>
> On Wed, Dec 11, 2013 at 2:21 PM, Bob Briscoe wrote:
>>
>> Jim,
>>
>>
>>
> >
> > True, however, it only means that you'll overshoot more or the time was
> > too short to retain the trained count in memory (and in that case CoDel
> > forgets it like you admit). Or do you think that the magic number applied
> > to count on the recall (was
Jim,
At 16:55 11/12/2013, Jim Gettys wrote:
On Tue, Dec 10, 2013 at 10:04 PM, Bob Briscoe
<<mailto:bob.bris...@bt.com>bob.bris...@bt.com> wrote:
Jim,
I'm just checking we're not talking past each other. I'll repeat two
quotes from each of us, then comment.
On
Jim,
I'm just checking we're not talking past each other. I'll repeat two
quotes from each of us, then comment.
On Thu, Dec 5, 2013 at 1:13 PM, Bob Briscoe
<<mailto:bob.bris...@bt.com>bob.bris...@bt.com> wrote:
3{New}. It SHOULD be possible to make different ins
which assumed that
only one instance of an AQM will handle both ECN-capable and
non-ECN-capable packets.
Bob
____________
Bob Briscoe, BT
_
y not be necessary to switch an ECN flow to
AQM-generated drops - it may be sufficient to
switch both ECN and drop traffic to tail drop at
the same time - when load exceeds the operating
region of the AQM as a whole. But, you may be right - needs more experiments.
Bob
Richard Scheffenegger
a network assuming there will be
more flows on faster links. So, in order to remain as responsive on
faster links, CoDel's control law will need to be tuned for the
expected number of flows before it is deployed on different size links.
Cheers
Greg, inline...
At 18:57 11/11/2013, Greg White wrote:
On 11/11/13, 9:02 AM, "Bob Briscoe" wrote:
>Greg,
>
>At 06:54 09/11/2013, Greg White wrote:
>>This is very interesting work. There are a lot of unanswered questions
>>about ecn / no-ecn coexistence and d
iling list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
________
Bob Briscoe, BT ___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
.
Is that what you meant?
Bob
-Greg
On 11/7/13, 1:03 PM, "Bob Briscoe" wrote:
>Folks,
>
>"Immediate ECN" slides:
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pptx>
><http://bobbriscoe.net/presents/1311ietf/1311tsvarea-iecn.pdf&g
his
effect), but I had to cut short, because I had to squeeze a 20min
presentation into the last 15 mins of tsvwg.
Regards
Bob
Thanks,
Rong
On 11/7/13 12:03 PM, "Bob Briscoe" wrote:
>Folks,
>
>"Immediate ECN" slides:
><http://bobbriscoe.net/presents
CoDel)
max_burst = 0 (for PIE)
Bob
PS. We have a paper under submission, which we can supply on request.
We plan to document this in the IETF too.
________
Bob Briscoe, BT
__
avoid impairment, whereas ECN
is solely a signal not an impairment, so there is no harm triggering
it earlier.
Cheers,
Piers
On 5 Nov 2013, at 18:41, Bob Briscoe wrote:
> Piers,
>
> I tried to state exactly how ECN can benefit (2nd para of intro
below), rather than make overblown claims.
/2013 10:59 AM, Bob Briscoe wrote:
Joe,
I envisage that a very brief standards track doc that explicitly UPDATES
the relevant IETF tunnel specs will be written, and it will refer to
this doc for rationale.
Tunnels need to handle ingress/egress translation of all signals in
the header. This
create it. - Alan Kay
Privacy matters! We know from recent events that people are using our
services to speak in defiance of unjust governments. We treat
privacy and security as matters of life and death, because for some
users, they are.
On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe
clearly useful work.
One thing that could do with clarification in the Introduction is
that ECN - by itself - doesn't necessarily lead to low loss and
delay - it should be made clear that it reflects the marking
approach of the underlying scheme/AQM.
Piers
On 4 Nov 2013, at 22:03, Bo
_ts.xml&productDetail=products/mpls.xml>specification).
Bob
____
Bob Briscoe, BT ___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
. :)
Bob
Willing to comment and review, at least.
On 5 November 2013 09:03, Bob Briscoe
<<mailto:bob.bris...@bt.com>bob.bris...@bt.com> wrote:
Folks,
Pls respond if you support this being adopted as a work-group item
in the IETF transport services w-g (tsvwg). The WG chairs ne
Fred,
At 22:39 04/11/2013, Fred Baker (fred) wrote:
On Nov 4, 2013, at 2:03 PM, Bob Briscoe wrote:
> Folks,
>
> Pls respond if you support this being adopted as a work-group
item in the IETF transport services w-g (tsvwg). The WG chairs need
visibility of interest.
And don
between new lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
[Cross-posting tsvwg & aqm, just in case]
Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil
_____
t's what we're doing.
On Sun, Oct 27, 2013 at 6:36 PM, Bob Briscoe wrote:
> John, inline...
>
> At 12:16 26/10/2013, John Leslie wrote:
>>
>> Bob Briscoe wrote:
>> >
>> > Exec summary
>> > * Early tests show promise that we may have
John, inline...
At 12:16 26/10/2013, John Leslie wrote:
Bob Briscoe wrote:
>
> Exec summary
> * Early tests show promise that we may have found a way to make the
> ultra-low queuing delay of data centre TCP incrementally deployable
> on the public Internet
> * For rtcweb,
Mat,
At 11:56 22/10/2013, Matthew Ford wrote:
On 22 Oct 2013, at 00:40, Bob Briscoe wrote:
> There's more to it - I've asked to present the whole story in Vancouver.
Cool, looking forward to it. I'll prime the question pump now if I may:
Does the transport need to know th
:35 15/10/2013, Dave Taht wrote:
It is my general assumption that membership in the aqm wg is a subset
of tsvwg, but in case it isn't...
-- Forwarded message --
From: Bob Briscoe
Date: Tue, Sep 17, 2013 at 5:33 AM
Subject: [tsvwg] Guidelines for Adding Congestion Notificati
ps://www.ietf.org/mailman/listinfo/aqm
____________
Bob Briscoe, BT
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
95 matches
Mail list logo
