* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-05-29 9:54 [Bloat] CFP: Workshop on Reducing Internet Latency Mat Ford
@ 2013-05-30 2:56 ` Dave Taht
2013-06-04 17:54 ` Jim Gettys
2013-06-11 10:51 ` Matthew Ford
2013-12-09 12:49 ` Matthew Ford
2 siblings, 1 reply; 12+ messages in thread
From: Dave Taht @ 2013-05-30 2:56 UTC (permalink / raw)
To: Matthew Ford; +Cc: bloat
[-- Attachment #1: Type: text/plain, Size: 4812 bytes --]
The proposed date for this event conflicts with linuxcon and the plumbers
conference.
http://events.linuxfoundation.org/events/linuxcon-north-america
If it were held concurrently or sequentially with that and preferably in
the same country... It would help.
On May 29, 2013 7:13 AM, "Mat Ford" <ford@isoc.org> wrote:
> This workshop may be of interest to folks here.
>
> Regards,
> Mat
>
> Workshop on Reducing Internet Latency
> =====================================
> 17-18 September 2013
> London, England
>
> Introduction and Scope
> ----------------------
> Latency tends to have been sacrificed in favour of headline bandwidth in
> the way the Internet has been built. This two-day invitation-only workshop
> aims to galvanise action to fix that. All layers of the stack are in scope.
>
> Latency is an increasingly important topic for networking researchers and
> Internet practitioners alike. Data from Google, Microsoft, Amazon and
> others indicate that latency increases for interactive Web applications
> result in less usage and less revenue from sales or advertising income.
> Whether trying to provide platforms for Web applications, high-frequency
> stock trading, multi-player online gaming or 'cloud' services of any kind,
> latency is a critical factor in determining end-user satisfaction and the
> success of products in the marketplace. Consequently, latency and
> variation in latency are key performance metrics for services these days.
>
> But latency reduction is not just about increasing revenues for big
> business. Matt Mullenweg of WordPress motivates work on latency reduction
> well when he says, "My theory here is when an interface is faster, you
> feel good. And ultimately what that comes down to is you feel in control.
> The [application] isn¹t controlling me, I¹m controlling it. Ultimately
> that feeling of control translates to happiness in everyone. In order to
> increase the happiness in the world, we all have to keep working on this."
>
> Invitations to attend the workshop will depend on receipt of a position
> paper. In a spirit of co-ordination across the industry, submissions are
> encouraged from developers and network operators as well as the research
> and standards communities.
>
> A wide range of latency related topics are in scope including, but not
> limited to:
> - surveys of latency across all layers
> - analyses of sources of latency and severity/variability
> - the cost of latency problems to society and the economy, or the
> value of
> fixing it
> - principles for latency reduction across the stack
> - solutions to reduce latency, including cross-layer
> - deployment considerations for latency reducing technology
> - benchmarking, accreditation, measurement and market comparison
> practices
>
> Submissions
> -----------
> This is an invitation-only workshop. Prospective participants must submit
> short (up to 2 pages) position papers outlining their views on a specific
> aspect of the overall scope. The emphasis here is on relevance and brevity
> - you do not need to write a lot of text, just demonstrate that you have
> thought about the problem space and have something interesting to say on
> the topic.
>
> Please send position papers in PDF format to: latency@isoc.org
>
> Participant numbers will be limited to focus on discussion and identifying
> actions rather than slideware.
>
> Accepted position papers will be made public. A report on the workshop
> will be published after participants have agreed the content. Therefore,
> it will be possible to state views during the workshop without them being
> publicly attributed.
>
> Important Dates
> ---------------
> Position paper submission deadline: 23 June 2013
> Paper acceptance notification: 28 June 2013
> Workshop dates: 9am, Tuesday 17th to 5pm, Wednesday 18th September 2013
> (subject to change)
>
> Program committee
> -----------------
> Mat Ford, Internet Society, co-chair
> Bob Briscoe, BT, co-chair
> Gorry Fairhurst, University of Aberdeen
> Arvind Jain, Google
> Jason Livingood, Comcast
> Andrew McGregor, Google
>
> Workshop venue and other details
> --------------------------------
> Venue: London (exact location to be confirmed)
> Registration fee: nil
> Recommended accommodation: To be confirmed
> The workshop is sponsored by the Internet Society, the RITE project,
> Simula Research Labs and the TimeIn project. The Internet Society will
> host a workshop dinner on the Tuesday evening.
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
[-- Attachment #2: Type: text/html, Size: 5543 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-05-30 2:56 ` Dave Taht
@ 2013-06-04 17:54 ` Jim Gettys
0 siblings, 0 replies; 12+ messages in thread
From: Jim Gettys @ 2013-06-04 17:54 UTC (permalink / raw)
To: Dave Taht; +Cc: bloat
[-- Attachment #1: Type: text/plain, Size: 6326 bytes --]
As Dave says, it's really unfortunate to schedule this on top of LPC: that
basically prevents anyone serious working on Linux networking attending. I
argue, that Linux is the most important OS right now to deal with, given
that Android, most internet servers, and home routers are all Linux based).
Linux is also by far furthest along in dealing with the problem, and moves
fastest.
Location is suboptimal, but such is life...
I expect the dates will cause heartburn for Andrew McGregor too, who we
hope/expect will be involved in fixing the Linux WiFi stack.
At a minimum rescheduling might get a few people who actually influence
code that is shipping there.... Increasing interactions between these
communities would be really, really wise as Dave says.
For future reference, there are three or so meetings a year that Linux
folks care about in general: LPC, the Kernel summit (if you're invited),
and LCA (linux Conf Australia, always in Late January/early February in
Austrailia or New Zealand). Individual teams may have other meetings as
well, but those are the big ones.
- Jim
On Wed, May 29, 2013 at 10:56 PM, Dave Taht <dave.taht@gmail.com> wrote:
> The proposed date for this event conflicts with linuxcon and the plumbers
> conference.
>
> http://events.linuxfoundation.org/events/linuxcon-north-america
>
> If it were held concurrently or sequentially with that and preferably in
> the same country... It would help.
> On May 29, 2013 7:13 AM, "Mat Ford" <ford@isoc.org> wrote:
>
>> This workshop may be of interest to folks here.
>>
>> Regards,
>> Mat
>>
>> Workshop on Reducing Internet Latency
>> =====================================
>> 17-18 September 2013
>> London, England
>>
>> Introduction and Scope
>> ----------------------
>> Latency tends to have been sacrificed in favour of headline bandwidth in
>> the way the Internet has been built. This two-day invitation-only workshop
>> aims to galvanise action to fix that. All layers of the stack are in
>> scope.
>>
>> Latency is an increasingly important topic for networking researchers and
>> Internet practitioners alike. Data from Google, Microsoft, Amazon and
>> others indicate that latency increases for interactive Web applications
>> result in less usage and less revenue from sales or advertising income.
>> Whether trying to provide platforms for Web applications, high-frequency
>> stock trading, multi-player online gaming or 'cloud' services of any kind,
>> latency is a critical factor in determining end-user satisfaction and the
>> success of products in the marketplace. Consequently, latency and
>> variation in latency are key performance metrics for services these days.
>>
>> But latency reduction is not just about increasing revenues for big
>> business. Matt Mullenweg of WordPress motivates work on latency reduction
>> well when he says, "My theory here is when an interface is faster, you
>> feel good. And ultimately what that comes down to is you feel in control.
>> The [application] isn¹t controlling me, I¹m controlling it. Ultimately
>> that feeling of control translates to happiness in everyone. In order to
>> increase the happiness in the world, we all have to keep working on this."
>>
>> Invitations to attend the workshop will depend on receipt of a position
>> paper. In a spirit of co-ordination across the industry, submissions are
>> encouraged from developers and network operators as well as the research
>> and standards communities.
>>
>> A wide range of latency related topics are in scope including, but not
>> limited to:
>> - surveys of latency across all layers
>> - analyses of sources of latency and severity/variability
>> - the cost of latency problems to society and the economy, or the
>> value of
>> fixing it
>> - principles for latency reduction across the stack
>> - solutions to reduce latency, including cross-layer
>> - deployment considerations for latency reducing technology
>> - benchmarking, accreditation, measurement and market comparison
>> practices
>>
>> Submissions
>> -----------
>> This is an invitation-only workshop. Prospective participants must submit
>> short (up to 2 pages) position papers outlining their views on a specific
>> aspect of the overall scope. The emphasis here is on relevance and brevity
>> - you do not need to write a lot of text, just demonstrate that you have
>> thought about the problem space and have something interesting to say on
>> the topic.
>>
>> Please send position papers in PDF format to: latency@isoc.org
>>
>> Participant numbers will be limited to focus on discussion and identifying
>> actions rather than slideware.
>>
>> Accepted position papers will be made public. A report on the workshop
>> will be published after participants have agreed the content. Therefore,
>> it will be possible to state views during the workshop without them being
>> publicly attributed.
>>
>> Important Dates
>> ---------------
>> Position paper submission deadline: 23 June 2013
>> Paper acceptance notification: 28 June 2013
>> Workshop dates: 9am, Tuesday 17th to 5pm, Wednesday 18th September 2013
>> (subject to change)
>>
>> Program committee
>> -----------------
>> Mat Ford, Internet Society, co-chair
>> Bob Briscoe, BT, co-chair
>> Gorry Fairhurst, University of Aberdeen
>> Arvind Jain, Google
>> Jason Livingood, Comcast
>> Andrew McGregor, Google
>>
>> Workshop venue and other details
>> --------------------------------
>> Venue: London (exact location to be confirmed)
>> Registration fee: nil
>> Recommended accommodation: To be confirmed
>> The workshop is sponsored by the Internet Society, the RITE project,
>> Simula Research Labs and the TimeIn project. The Internet Society will
>> host a workshop dinner on the Tuesday evening.
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
[-- Attachment #2: Type: text/html, Size: 8127 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-05-29 9:54 [Bloat] CFP: Workshop on Reducing Internet Latency Mat Ford
2013-05-30 2:56 ` Dave Taht
@ 2013-06-11 10:51 ` Matthew Ford
2013-12-09 12:49 ` Matthew Ford
2 siblings, 0 replies; 12+ messages in thread
From: Matthew Ford @ 2013-06-11 10:51 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 4375 bytes --]
On 29 May 2013, at 10:54, Mat Ford <ford@isoc.org> wrote:
> This workshop may be of interest to folks here.
>
> Regards,
> Mat
8< snip >8
Dates for this workshop have moved and are now final.
The workshop will be held in London on 25-26 September.
A revised and final CFP is attached, and below.
Regards,
Mat
Workshop on Reducing Internet Latency
=====================================
25 - 26 September 2013
London, England
Latency tends to have been sacrificed in favour of headline bandwidth in the way the Internet has been built. This two-day invitation-only workshop aims to galvanise action to fix that. All layers of the stack are in scope.
Latency is an increasingly important topic for networking researchers and Internet practitioners alike. Data from Google, Microsoft, Amazon and others indicate that latency increases for interactive Web applications result in less usage and less revenue from sales or advertising income. Whether trying to provide platforms for Web applications, high-frequency stock trading, multi-player online gaming or 'cloud' services of any kind, latency is a critical factor in determining end-user satisfaction and the success of products in the marketplace. Consequently, latency and variation in latency are key performance metrics for services these days.
But latency reduction is not just about increasing revenues for big business. Matt Mullenweg of WordPress motivates work on latency reduction well when he says, "My theory here is when an interface is faster, you feel good. And ultimately what that comes down to is you feel in control. The [application] isn’t controlling me, I’m controlling it. Ultimately that feeling of control translates to happiness in everyone. In order to increase the happiness in the world, we all have to keep working on this."
Invitations to attend the workshop will depend on receipt of a position paper. In a spirit of co- ordination across the industry, submissions are encouraged from developers and network operators as well as the research and standards communities.
A wide range of latency related topics are in scope including, but not limited to:
- surveys of latency across all layers
- analyses of sources of latency and severity/variability
- the cost of latency problems to society and the economy, or the value of fixing it
- principles for latency reduction across the stack
- solutions to reduce latency, including cross-layer
- deployment considerations for latency reducing technology
- benchmarking, accreditation, measurement and market comparison practices
Submissions
-----------
This is an invitation-only workshop. Prospective participants must submit short (up to 2 pages) position papers outlining their views on a specific aspect of the overall scope. The emphasis here is on relevance and brevity - you do not need to write a lot of text, just demonstrate that you have thought about the problem space and have something interesting to say on the topic.
Please send position papers in PDF format to: latency@isoc.org
Participant numbers will be limited to focus on discussion and identifying actions rather than slideware.
Accepted position papers will be made public. A report on the workshop will be published after participants have agreed the content. Therefore, it will be possible to state views during the workshop without them being publicly attributed.
Important Dates
---------------
Position paper submission deadline: 23 June 2013
Paper acceptance notification: 28 June 2013
Workshop dates: 9am, Wednesday 25th – 5pm, Thursday 26th September 2013
Program committee
-----------------
Mat Ford, Internet Society, co-chair
Bob Briscoe, BT, co-chair
Gorry Fairhurst, University of Aberdeen
Arvind Jain, Google
Jason Livingood, Comcast
Andrew McGregor, Google
Workshop venue and other details
--------------------------------
Venue: Hilton London Paddington Hotel, 146 Praed Street, LONDON W2 1EE, UK
Registration fee: There is no registration fee for the workshop.
Recommended accommodation: Hilton London Paddington, registration link will be supplied to accepted participants.
The workshop is sponsored by the Internet Society, the RITE project, Simula Research Labs and the TimeIn project.
The Internet Society will host a workshop dinner on the Wednesday evening.
[-- Attachment #2: WkshpReducingLatency.pdf --]
[-- Type: application/pdf, Size: 75228 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-05-29 9:54 [Bloat] CFP: Workshop on Reducing Internet Latency Mat Ford
2013-05-30 2:56 ` Dave Taht
2013-06-11 10:51 ` Matthew Ford
@ 2013-12-09 12:49 ` Matthew Ford
2013-12-10 6:48 ` Mikael Abrahamsson
2 siblings, 1 reply; 12+ messages in thread
From: Matthew Ford @ 2013-12-09 12:49 UTC (permalink / raw)
To: bloat
The report of the Reducing Internet Latency workshop is now available:
http://www.internetsociety.org/blog/2013/12/speeding-internet-reducing-latency
Regards,
Mat
On 29 May 2013, at 10:54, Mat Ford <ford@isoc.org> wrote:
> This workshop may be of interest to folks here.
>
> Regards,
> Mat
>
> Workshop on Reducing Internet Latency
> =====================================
> 17-18 September 2013
> London, England
>
> Introduction and Scope
> ----------------------
> Latency tends to have been sacrificed in favour of headline bandwidth in
> the way the Internet has been built. This two-day invitation-only workshop
> aims to galvanise action to fix that. All layers of the stack are in scope.
>
> Latency is an increasingly important topic for networking researchers and
> Internet practitioners alike. Data from Google, Microsoft, Amazon and
> others indicate that latency increases for interactive Web applications
> result in less usage and less revenue from sales or advertising income.
> Whether trying to provide platforms for Web applications, high-frequency
> stock trading, multi-player online gaming or 'cloud' services of any kind,
> latency is a critical factor in determining end-user satisfaction and the
> success of products in the marketplace. Consequently, latency and
> variation in latency are key performance metrics for services these days.
>
> But latency reduction is not just about increasing revenues for big
> business. Matt Mullenweg of WordPress motivates work on latency reduction
> well when he says, "My theory here is when an interface is faster, you
> feel good. And ultimately what that comes down to is you feel in control.
> The [application] isn¹t controlling me, I¹m controlling it. Ultimately
> that feeling of control translates to happiness in everyone. In order to
> increase the happiness in the world, we all have to keep working on this."
>
> Invitations to attend the workshop will depend on receipt of a position
> paper. In a spirit of co-ordination across the industry, submissions are
> encouraged from developers and network operators as well as the research
> and standards communities.
>
> A wide range of latency related topics are in scope including, but not
> limited to:
> - surveys of latency across all layers
> - analyses of sources of latency and severity/variability
> - the cost of latency problems to society and the economy, or the value of
> fixing it
> - principles for latency reduction across the stack
> - solutions to reduce latency, including cross-layer
> - deployment considerations for latency reducing technology
> - benchmarking, accreditation, measurement and market comparison practices
>
> Submissions
> -----------
> This is an invitation-only workshop. Prospective participants must submit
> short (up to 2 pages) position papers outlining their views on a specific
> aspect of the overall scope. The emphasis here is on relevance and brevity
> - you do not need to write a lot of text, just demonstrate that you have
> thought about the problem space and have something interesting to say on
> the topic.
>
> Please send position papers in PDF format to: latency@isoc.org
>
> Participant numbers will be limited to focus on discussion and identifying
> actions rather than slideware.
>
> Accepted position papers will be made public. A report on the workshop
> will be published after participants have agreed the content. Therefore,
> it will be possible to state views during the workshop without them being
> publicly attributed.
>
> Important Dates
> ---------------
> Position paper submission deadline: 23 June 2013
> Paper acceptance notification: 28 June 2013
> Workshop dates: 9am, Tuesday 17th to 5pm, Wednesday 18th September 2013
> (subject to change)
>
> Program committee
> -----------------
> Mat Ford, Internet Society, co-chair
> Bob Briscoe, BT, co-chair
> Gorry Fairhurst, University of Aberdeen
> Arvind Jain, Google
> Jason Livingood, Comcast
> Andrew McGregor, Google
>
> Workshop venue and other details
> --------------------------------
> Venue: London (exact location to be confirmed)
> Registration fee: nil
> Recommended accommodation: To be confirmed
> The workshop is sponsored by the Internet Society, the RITE project,
> Simula Research Labs and the TimeIn project. The Internet Society will
> host a workshop dinner on the Tuesday evening.
>
> <WkshpReducingLatency.pdf>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-12-09 12:49 ` Matthew Ford
@ 2013-12-10 6:48 ` Mikael Abrahamsson
2013-12-10 7:54 ` Neil Davies
2013-12-10 8:48 ` [Bloat] CFP: Workshop on Reducing Internet Latency MUSCARIELLO Luca IMT/OLN
0 siblings, 2 replies; 12+ messages in thread
From: Mikael Abrahamsson @ 2013-12-10 6:48 UTC (permalink / raw)
To: Matthew Ford; +Cc: bloat
On Mon, 9 Dec 2013, Matthew Ford wrote:
> The report of the Reducing Internet Latency workshop is now available:
>
> http://www.internetsociety.org/blog/2013/12/speeding-internet-reducing-latency
Reading through this I generally like it. It's a good summary and
introduction.
However, this part:
"Hiding packet losses in broadband lines using interleaving can add about
20ms of delay, even though modern transports and applications are robust
to such low packet loss levels;"
Having been part of a decently sized ADSL2+ deployment ISP, I have some
experience with this and the above doesn't match them. We actually did get
customer complaints when we were running ADSL2+ in fast-mode (no
interleaving), that the customers were getting packet losses that affected
their applications.
So I would have liked the above to not say "broadband lines" but instead
said ADSL(2+) broadband lines (because the above statement only relates to
ADSL(2+) afaik), and also that the packet losses can be non-trivial for
some and that ISPs don't turn on interleaving out of ignorance. It's hard
to measure customer impact of "errored seconds" which is the only way the
ISP can see packet losses. Also, these errored seconds can be quite
severer when it comes to number of packets dropped.
We actually did talk about having a self-service portal where the customer
could choose their preferred profile, either fast (no interleaving), 4ms
or 16 ms interleaving, and also their safety margin to 6, 9 or 12 dB. Fast
or 4ms interleaving worked well with 12 dB SNR margin (which means lower
latency but also lower access speeds), whereas 6dB margin often required
16ms interleaving to work well.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-12-10 6:48 ` Mikael Abrahamsson
@ 2013-12-10 7:54 ` Neil Davies
2013-12-10 8:04 ` [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency) Mikael Abrahamsson
2013-12-10 8:48 ` [Bloat] CFP: Workshop on Reducing Internet Latency MUSCARIELLO Luca IMT/OLN
1 sibling, 1 reply; 12+ messages in thread
From: Neil Davies @ 2013-12-10 7:54 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: bloat
Mikael
Your statements about ADSL2+ are interesting; I've been looking at deployments where the SNR is "ok" but (by measurement) 20% packet loss is occurring. This state can last for several minutes, resolved by a re-train (but that has to be initiated manually from the customer end).
Our current "hypothesis" is that specific frequencies are suffering due to very specific (narrow) changes in the transmission characteristics - "slot filters" that come into existence (due to changes in environmental conditions) then disappear.
We've seen this even when we've played with the settings through the customer portal (I'm' in the UK - the provisioning portal allows many such changes).
Are you capturing any evidence of DSL modem state when this occurs?
Neil
On 10 Dec 2013, at 06:48, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Mon, 9 Dec 2013, Matthew Ford wrote:
>
>> The report of the Reducing Internet Latency workshop is now available:
>>
>> http://www.internetsociety.org/blog/2013/12/speeding-internet-reducing-latency
>
> Reading through this I generally like it. It's a good summary and introduction.
>
> However, this part:
> "Hiding packet losses in broadband lines using interleaving can add about 20ms of delay, even though modern transports and applications are robust to such low packet loss levels;"
>
> Having been part of a decently sized ADSL2+ deployment ISP, I have some experience with this and the above doesn't match them. We actually did get customer complaints when we were running ADSL2+ in fast-mode (no interleaving), that the customers were getting packet losses that affected their applications.
>
> So I would have liked the above to not say "broadband lines" but instead said ADSL(2+) broadband lines (because the above statement only relates to ADSL(2+) afaik), and also that the packet losses can be non-trivial for some and that ISPs don't turn on interleaving out of ignorance. It's hard to measure customer impact of "errored seconds" which is the only way the ISP can see packet losses. Also, these errored seconds can be quite severer when it comes to number of packets dropped.
>
> We actually did talk about having a self-service portal where the customer could choose their preferred profile, either fast (no interleaving), 4ms or 16 ms interleaving, and also their safety margin to 6, 9 or 12 dB. Fast or 4ms interleaving worked well with 12 dB SNR margin (which means lower latency but also lower access speeds), whereas 6dB margin often required 16ms interleaving to work well.
>
> --
> Mikael Abrahamsson email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency)
2013-12-10 7:54 ` Neil Davies
@ 2013-12-10 8:04 ` Mikael Abrahamsson
2013-12-10 8:07 ` Neil Davies
0 siblings, 1 reply; 12+ messages in thread
From: Mikael Abrahamsson @ 2013-12-10 8:04 UTC (permalink / raw)
To: Neil Davies; +Cc: bloat
On Tue, 10 Dec 2013, Neil Davies wrote:
> We've seen this even when we've played with the settings through the
> customer portal (I'm' in the UK - the provisioning portal allows many
> such changes).
>
> Are you capturing any evidence of DSL modem state when this occurs?
Well, we saw the problems mostly on medium-short spans, such as 1000-1500
meters. The packet loss wasn't as high as 20%, but it was consistant over
time and showed up as errored seconds. I do not work there anymore, and
this was 7 years ago.
Interleaving spans bits over longer period of time, so if you're running
fast mode and you get a 1ms "hit" on the link, the FEC (forward error
correction) gets too many bits corrupted and gets overwhelmed. If one
instead has 16ms interleaving, a lot fewer bits from one packet gets
corrupted, and FEC can correct the errors.
So your theory about line noise on specific frequencies is probably
correct, you're not getting a big enough hit to trigger a re-train, but
you're getting enough bit errors to cause post-FEC errors and thus packet
loss. A re-train probably identifies the noise on those frequencies and
uses them less.
In our DSLAM we could see the frequency band profile via a show command,
have you done this?
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency)
2013-12-10 8:04 ` [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency) Mikael Abrahamsson
@ 2013-12-10 8:07 ` Neil Davies
0 siblings, 0 replies; 12+ messages in thread
From: Neil Davies @ 2013-12-10 8:07 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: bloat
Don't have direct access to the DSLAM, but do have access to that information in the modem - and yes and there appears to be a large change in certain frequency buckets.
The loss rates appear to vary with the offered load - i.e the "loss" only occurs if there was real packet data in that frequency band
On 10 Dec 2013, at 08:04, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 10 Dec 2013, Neil Davies wrote:
>
>> We've seen this even when we've played with the settings through the customer portal (I'm' in the UK - the provisioning portal allows many such changes).
>>
>> Are you capturing any evidence of DSL modem state when this occurs?
>
> Well, we saw the problems mostly on medium-short spans, such as 1000-1500 meters. The packet loss wasn't as high as 20%, but it was consistant over time and showed up as errored seconds. I do not work there anymore, and this was 7 years ago.
>
> Interleaving spans bits over longer period of time, so if you're running fast mode and you get a 1ms "hit" on the link, the FEC (forward error correction) gets too many bits corrupted and gets overwhelmed. If one instead has 16ms interleaving, a lot fewer bits from one packet gets corrupted, and FEC can correct the errors.
>
> So your theory about line noise on specific frequencies is probably correct, you're not getting a big enough hit to trigger a re-train, but you're getting enough bit errors to cause post-FEC errors and thus packet loss. A re-train probably identifies the noise on those frequencies and uses them less.
>
> In our DSLAM we could see the frequency band profile via a show command, have you done this?
>
> --
> Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-12-10 6:48 ` Mikael Abrahamsson
2013-12-10 7:54 ` Neil Davies
@ 2013-12-10 8:48 ` MUSCARIELLO Luca IMT/OLN
2013-12-10 9:36 ` Mikael Abrahamsson
1 sibling, 1 reply; 12+ messages in thread
From: MUSCARIELLO Luca IMT/OLN @ 2013-12-10 8:48 UTC (permalink / raw)
To: Mikael Abrahamsson, Matthew Ford; +Cc: bloat
On 12/10/2013 07:48 AM, Mikael Abrahamsson wrote:
>
> So I would have liked the above to not say "broadband lines" but
> instead said ADSL(2+) broadband lines (because the above statement
> only relates to ADSL(2+) afaik), and also that the packet losses can
> be non-trivial for some and that ISPs don't turn on interleaving out
> of ignorance. It's hard to measure customer impact of "errored
> seconds" which is the only way the ISP can see packet losses. Also,
> these errored seconds can be quite severer when it comes to number of
> packets dropped.
it applies to ADSL to court.
>
> We actually did talk about having a self-service portal where the
> customer could choose their preferred profile, either fast (no
> interleaving), 4ms or 16 ms interleaving, and also their safety margin
> to 6, 9 or 12 dB. Fast or 4ms interleaving worked well with 12 dB SNR
> margin (which means lower latency but also lower access speeds),
> whereas 6dB margin often required 16ms interleaving to work well.
Was that successful? Did customers use that?
Usually it is not, but I'd like to know about your experience.
Luca
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-12-10 8:48 ` [Bloat] CFP: Workshop on Reducing Internet Latency MUSCARIELLO Luca IMT/OLN
@ 2013-12-10 9:36 ` Mikael Abrahamsson
2013-12-10 9:40 ` MUSCARIELLO Luca IMT/OLN
0 siblings, 1 reply; 12+ messages in thread
From: Mikael Abrahamsson @ 2013-12-10 9:36 UTC (permalink / raw)
To: MUSCARIELLO Luca IMT/OLN; +Cc: bloat
On Tue, 10 Dec 2013, MUSCARIELLO Luca IMT/OLN wrote:
>> We actually did talk about having a self-service portal where the customer
>> could choose their preferred profile, either fast (no interleaving), 4ms or
>> 16 ms interleaving, and also their safety margin to 6, 9 or 12 dB. Fast or
>> 4ms interleaving worked well with 12 dB SNR margin (which means lower
>> latency but also lower access speeds), whereas 6dB margin often required
>> 16ms interleaving to work well.
>
> Was that successful? Did customers use that?
> Usually it is not, but I'd like to know about your experience.
We only talked about it, it was never implemented (at least not when I was
there). We however made the different profiles available to customer
service, so customers could call in and have their profiles set to
whatever suited them best.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bloat] CFP: Workshop on Reducing Internet Latency
2013-12-10 9:36 ` Mikael Abrahamsson
@ 2013-12-10 9:40 ` MUSCARIELLO Luca IMT/OLN
0 siblings, 0 replies; 12+ messages in thread
From: MUSCARIELLO Luca IMT/OLN @ 2013-12-10 9:40 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: bloat
On 12/10/2013 10:36 AM, Mikael Abrahamsson wrote:
> On Tue, 10 Dec 2013, MUSCARIELLO Luca IMT/OLN wrote:
>
>>> We actually did talk about having a self-service portal where the
>>> customer could choose their preferred profile, either fast (no
>>> interleaving), 4ms or 16 ms interleaving, and also their safety
>>> margin to 6, 9 or 12 dB. Fast or 4ms interleaving worked well with
>>> 12 dB SNR margin (which means lower latency but also lower access
>>> speeds), whereas 6dB margin often required 16ms interleaving to work
>>> well.
>>
>> Was that successful? Did customers use that?
>> Usually it is not, but I'd like to know about your experience.
>
> We only talked about it, it was never implemented (at least not when I
> was there). We however made the different profiles available to
> customer service, so customers could call in and have their profiles
> set to whatever suited them best.
>
The approach you mention is way more general.
Having a portal to manage per-customer last-mile QoS requirements (and
the protocols to enforce that choice) is interesting.
I am curious to know if customers are used to call to set their profile.
^ permalink raw reply [flat|nested] 12+ messages in thread