> there are a multitude of papers posted for the buffer sizing workshop
>
> http://buffer-workshop.stanford.edu/papers/paper23.pdf was interesting.
Would be nice to get them to add ECN(sce) to the mix of there tests.
> On Fri, Nov 29, 2019 at 12:08 PM Dave Taht wrote:
> >
> > there are no minut
> > there are no minutes posted.
> >
> > https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-81-some-congestion-experienced-00
> >
> > https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-some-congestion-experienced-in-tcp-00
>
> The above 2 decks are identica
> Hi Jonathan,
>
>
> > On Nov 30, 2019, at 23:23, Jonathan Morton wrote:
> >
> >> On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote:
> >>
> >>> There are unfortunate problems with introducing new TCP options, in that
> >>> some overzealous firewalls block traffic which uses them. This woul
> there are no minutes posted.
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-81-some-congestion-experienced-00
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-some-congestion-experienced-in-tcp-00
The above 2 decks are identical. Jonathan d
> On Dec 2, 2019, at 6:38 AM, Dave Taht wrote:
>
> I do hate watching y'all continually concede the "latency" point and
> have to argue on the "chosen ground" of single or dualq about
> long-running tcp flows.
I don’t think we’ve conceded that. It would be possible to run more tests on a
LAN
Hi Dave,
On December 2, 2019 6:38:11 AM GMT+01:00, Dave Taht wrote:
>Jonathan Morton writes:
>
>>> On 30 Nov, 2019, at 5:42 pm, Sebastian Moeller
>wrote:
>>>
> I fear that they will come up with something that in reality will
a) by opt-out, that is they will assume L4S-style feedback
Hi Dave,
On December 2, 2019 6:10:51 AM GMT+01:00, Dave Taht wrote:
>Sebastian Moeller writes:
>
>> Hi Rodney,
>>
>>
>>> On Dec 1, 2019, at 18:30, Rodney W. Grimes <4b...@gndrsh.dnsmgr.net>
>wrote:
>>>
Hi Jonathan,
> On Nov 30, 2019, at 23:23, Jonathan Morton
>wrote:
>
Jonathan Morton writes:
>> On 30 Nov, 2019, at 5:42 pm, Sebastian Moeller wrote:
>>
I fear that they will come up with something that in reality will
>>> a) by opt-out, that is they will assume L4S-style feedback until
>>> reluctantly convinced that the bottleneck marker is
>>> rfc3160-com
Sebastian Moeller writes:
> Hi Rodney,
>
>
>> On Dec 1, 2019, at 18:30, Rodney W. Grimes <4b...@gndrsh.dnsmgr.net> wrote:
>>
>>> Hi Jonathan,
>>>
>>>
On Nov 30, 2019, at 23:23, Jonathan Morton wrote:
> On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote:
>
>> There are
> On 1 Dec, 2019, at 9:32 pm, Sebastian Moeller wrote:
>
>> Meanwhile, an ack filter that avoids dropping acks in which the reserved
>> flag bits differ from its successor will not lose any information in the
>> one-bit scheme. This is what's implemented in Cake (except that not all the
>> re
Hi Jonathan,
> On Dec 1, 2019, at 20:27, Jonathan Morton wrote:
>
>> On 1 Dec, 2019, at 9:03 pm, Sebastian Moeller wrote:
>>
>>> If less feedback is observed by the sender than intended by the AQM, growth
>>> will continue and the AQM will increase its marking to compensate,
>>> ultimately
> On 1 Dec, 2019, at 9:03 pm, Sebastian Moeller wrote:
>
>> If less feedback is observed by the sender than intended by the AQM, growth
>> will continue and the AQM will increase its marking to compensate,
>> ultimately resorting to a CE mark.
>
> Well, that seems undesirable?
As a safety v
Hi Rodney,
> On Dec 1, 2019, at 18:30, Rodney W. Grimes <4b...@gndrsh.dnsmgr.net> wrote:
>
>> Hi Jonathan,
>>
>>
>>> On Nov 30, 2019, at 23:23, Jonathan Morton wrote:
>>>
On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote:
> There are unfortunate problems with introducing new
Hi Jonathan,
> On Dec 1, 2019, at 17:54, Jonathan Morton wrote:
>
>> On 1 Dec, 2019, at 6:35 pm, Sebastian Moeller wrote:
>>
>> Belt and suspenders, eh? But realistically, the idea of using an
>> accumulating SCE counter to allow for a lossy reverse ACK path seems sort of
>> okay (after all
I wonder if an inexpensive and credible test of the acceptability of
(URG(0) && urgent pointer > 0) by middle boxes might be possible using
load-testing/reachability services like NeoLoad or Pingdom?
On 2019-12-01 11:35 a.m., Sebastian Moeller wrote:
Hi Jonathan,
On Nov 30, 2019, at 23:23,
> On 1 Dec, 2019, at 6:35 pm, Sebastian Moeller wrote:
>
> Belt and suspenders, eh? But realistically, the idea of using an accumulating
> SCE counter to allow for a lossy reverse ACK path seems sort of okay (after
> all TCP relies on the same, so there would be a nice symmetry ).
Sure, we did
Hi Jonathan,
> On Nov 30, 2019, at 23:23, Jonathan Morton wrote:
>
>> On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote:
>>
>>> There are unfortunate problems with introducing new TCP options, in that
>>> some overzealous firewalls block traffic which uses them. This would be a
>>> deploy
> On 1 Dec, 2019, at 12:17 am, Carsten Bormann wrote:
>
>> There are unfortunate problems with introducing new TCP options, in that
>> some overzealous firewalls block traffic which uses them. This would be a
>> deployment hazard for SCE, which merely using a spare header flag avoids.
>> So
On Nov 30, 2019, at 15:32, Jonathan Morton wrote:
>
> There are unfortunate problems with introducing new TCP options, in that some
> overzealous firewalls block traffic which uses them. This would be a
> deployment hazard for SCE, which merely using a spare header flag avoids. So
> instead
> On 30 Nov, 2019, at 5:42 pm, Sebastian Moeller wrote:
>
>>> I fear that they will come up with something that in reality will a) by
>>> opt-out, that is they will assume L4S-style feedback until reluctantly
>>> convinced that the bottleneck marker is rfc3160-compliant and hence will b)
>>> t
Hi Jonathan,
thanks, more below.
> On Nov 30, 2019, at 15:32, Jonathan Morton wrote:
>
>>> 2: Accurate ECN Feedback.
>>>
>>> We use a spare bit in the header of TCP acks to feed back SCE marks, and
>>> the existing ECE/CWR mechanism from RFC-3168 unchanged for CE marks. The
>>> SCE feedback
>> 2: Accurate ECN Feedback.
>>
>> We use a spare bit in the header of TCP acks to feed back SCE marks, and the
>> existing ECE/CWR mechanism from RFC-3168 unchanged for CE marks. The SCE
>> feedback is "accurate" but not "reliable", because it can tolerate large
>> errors (as much as 100% rel
Hi Jonathan,
> On Nov 30, 2019, at 02:39, Jonathan Morton wrote:
>
>> I don't see what you gain by going after the Prague requirements. They're
>> internal requirements for a TCP that would fulfill the L4S goals if
>> classified into the L4S side of a DualQ AQM: 'Packet Identification' means
23 matches
Mail list logo
