Ingemar Johansson S | 26 May 13:38 2015
Picon

TCP HyStart patch deployment

Hi

Does anybody know if the TCP Cubic HyStart patch described in the link below is being used widely ?
It does not seem to be implemented in the latest Linux code.
http://patchwork.ozlabs.org/patch/85945/

Regards
Ingemar
=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson <at> ericsson.com<mailto:ingemar.s.johansson <at> ericsson.com>
www.ericsson.com

"No man has a good enough memory
  to be a successful liar"
    Abraham Lincoln<http://www.brainyquote.com/quotes/authors/a/abraham_lincoln.html>
=================================

_______________________________________________
end2end-interest mailing list
end2end-interest <at> postel.org
http://mailman.postel.org/mailman/listinfo/end2end-interest
(Continue reading)

Debarshi Sanyal | 6 May 08:14 2015
Picon

Regarding use of Reed-Solomon code in wireless networks

Hi,

Hi,

We were working on design of wormhole detection methods in MANETs.
To achieve detection, we propose to measure the time taken for a test nonce
to move from one node to it's neighbor node. If the time taken is larger
than the expected time for a packet to travel between two neighbor nodes,
the link is probably a wormhole link.

Now to combat channel errors, is it worth encoding the nonce with
Reed-Solomon code?

Our understanding is that propagation time between neighbor nodes in
commodity wi-fi setups is much smaller than the time taken to encode and
decode a nonce (say, 64 bytes long). So delay variations in encode/decode
process will easily mask any delay in propagation time.

We would be immensely thankful if you could throw some light on this since
we do not have access to hardware platforms to get real measurements. We
are interested to know the approximate encode and decode times for RS code
on common hardware platforms.

Regards,
Debarshi Kumar Sanyal
KIIT University, Bhubaneswar, India
_______________________________________________
end2end-interest mailing list
end2end-interest <at> postel.org
http://mailman.postel.org/mailman/listinfo/end2end-interest
(Continue reading)

Djamel Sadok | 5 May 12:29 2015
Picon

Re: j'accuse NFV

nothing is wrong with e2e encryption. Perhaps all traffic will be encrypted
in a few years anyway.

I only want to find out if there could be a way to adopt NFV while leaving
a choice for traffic that does not want to be NFV´ed perhaps because of the
fear that some middlebox function (NFV) may alter some e2e
http2/QUIC/SPDY/.. clever adaptation that booble engineers have  just come
up with.

Djamel

On Mon, May 4, 2015 at 6:24 PM, <dpreed <at> reed.com> wrote:

> What's wrong with e2e encryption as the right answer?  I'm missing
> something here.
>
>
>
> On Monday, May 4, 2015 1:55pm, "Djamel Sadok" <jamel <at> cin.ufpe.br> said:
>
>  > To have a FW is difficult (performance wise) and sometimes illegal to
> have
> > DPI on the subnet to build an IDS.
> >
> > But what happens when everyone bypasses NFVs?
> >
> > Still, it could be necessary to maintain both religions side by side. But
> > how can a user check that its packets have not been NFV´ed by some
> > functions? other than e2e encrypting?
> >
(Continue reading)

Khaled Elsayed | 5 May 10:55 2015
Picon

Re: j'accuse NFV

But if endpoints have such choice to bypass or turn off, would there be any
endpoint out there that would choose not to?

On Mon, May 4, 2015 at 5:14 PM, David P. Reed <dpreed <at> reed.com> wrote:

> This argument presumes that firewalls work.... of course they can know
> neither the meaning of the packet to the sender nor the meaning to the
> receiver. So just as an air filter cannot protect your ears from shocking
> utterances,  the idea that a packet firewall ought to be entrusted to
> protect communicators from mischief is silly...
>
> Of course the endpoints need to be able to shut down or to bypass such
> "helpful" things as firewalls. They are at best kludges.
>
> On May 4, 2015, Khaled Elsayed <kelsayed <at> gmail.com> wrote:
>
>> You mean like a hacking packet would say please don't process me via that
>> nifty NFV firewall or something :-)
>>
>> Khaled
>>
>>
>> On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok <jamel <at> cin.ufpe.br> wrote:
>>
>> Hi,
>>>
>>> May be we could also give the end user flow the possibility to say that
>>> it
>>> does not want to have its data packets processed by any NFV or even black
>>> list some NFVs (types of functions) on the path. Would this be possible
(Continue reading)

Detlef Bosau | 1 May 23:53 2015
Picon

Re: A very prominent example for the "bandwidth fallacy" and LFN in mobile networks.

In a sense, Ham is nothing else than "WiFi in big" :-) So, the problems
should be pretty much the same.

Perhaps, Ham misses the /CA and the line coding is  certainly more
simple than in WiFi, but the basics should be very similar.

Am 01.05.2015 um 20:40 schrieb David P. Reed:
> Detlef's comments make huge sense to me. I'm a Ham licensee and also
> quite aware of physics and networks. The nonsense in the peer review
> ed literature is shameful for the most part.
>
> On May 1, 2015, Detlef Bosau <detlef.bosau <at> web.de> wrote:
>
>     The following article deals with GPRS.
>
>          <at> article{ meyer,
>         author ="Michael Meyer and Joachim Sachs and Markus Holzke",
>         title ="{Performance Evaluation of A TCP Proxy in WCDMA
>         Networks}",
>         journal ="IEEE Wireless Communications",
>         year = "2003",
>         month = "October"
>         }
>
>
>
>
>     Let me quote only a short passage from "TCP in the context of WCDMA":
>
>         Depending on the assigned data rate,
(Continue reading)

Jon Crowcroft | 29 Apr 11:34 2015
Picon
Picon

j'accuse NFV

Try as I might, I cannot really see Network Function Virtualization as much
more than yet another telco landgrab on internet stuff. But somewhat more
critically, I vew the idea of taking some of our precious middle bodily
fluid flow processing functions, and moving them a) off the box built by a
middlebox expert, and b) off the direct path, as actually
counter-productive. Lets just take three boring run-of-the-arithmetic-mill
such services:-

load balancer - this is on the latency critical path before you get to any
service - additional latency/hops/virtualization overhead is
counter-indicated by any sane business model

wan accelerator - especially for 2.9x-4.8xG wireless data networking
services - these are kind of rather localized by definition, right? I mean
they are dealing with impedance mis-matches in the interweb (tcp splice,
etc - see
https://www.icsi.berkeley.edu/icsi/publication_details?n=3730

firewall (or ids) - so these sit on trust boundaries, so it seems like a
reduction in security to move them anywhere (like above a hypervisor,
unless people are running, say, seL4:-), plus they might also be protecting
the infrastructure itself as well as customers, so it would seem
counter-productive to increase their attach surface in any way

So ok, not all virtualization involves moving stuff to a different location
often. But it does also imply some resource pooling (i.e. more than 1
instance of a Foo in the NFooV is running above the hyperv) - so this seems
like you might be buying into a wealth of pain with elasticity, when you
had just nailed down super-hard multiplexed allocation of cycles for
forwarding or filtering or protocol adaptation or responsive redirection
(Continue reading)

anjali chawla | 3 Jan 07:31 2015
Picon

RED vs DropTail using NS2

Hi
i want to prove that RED is better than DropTail using NS2. i have followed
"Random Early Detection Gateways for Congestion Avoidance,1993 " paper
also. For showing RED solves global synchronization problem,bias againt
bursty traffic,
i tried a lot using tcl script making different scenarios. But no useful
results at all.
In my case packet loss is more in RED than  DropTail.
 somenone please help
_______________________________________________
end2end-interest mailing list
end2end-interest <at> postel.org
http://mailman.postel.org/mailman/listinfo/end2end-interest
Contact list-owner <at> postel.org for assistance.

Joe Touch | 22 Oct 03:47 2014
Picon

updated E2E list advisory board

Hi, all,

Henning Schulzrinne and Scott Brim's terms as members of the
E2E-Interest email list Advisory Board have completed. Although we had
no significant email issues during that time, I would like to thank them
for offering their service.

I'd also like to welcome Fred Baker and Wes Eddy as new members to the
advisory board, hoping that their service is similarly uneventful.

Thanks to all,

Joe (as list admin)
_______________________________________________
end2end-interest mailing list
end2end-interest <at> postel.org
http://mailman.postel.org/mailman/listinfo/end2end-interest
Contact list-owner <at> postel.org for assistance.

Martin Heusse | 22 Sep 21:17 2014
Picon
Picon

Deflating excessive buffers

Dear E2E list,

in case it matches your curiosity, I wanted to point to the work we just presented at ITC'26 and maybe gather
your comments (T. Braud, M. Heusse, A. Duda: "TCP over Large Buffers: When Adding Traffic Improves
Latency"). (BTW, I don't see too many people talking about their work, so I'm not sure it's the usage to do
this... But since my posts to this list were sometimes sarcastic I also thought it would be an opportunity
to contribute in a different way!)

The has been many exchanges on this list about the impact of having excessively large buffers at the head of
the bottleneck link, which increases queueing delay and hurts link utilization --often in the downlink
direction, whereas the congestion is more often in the uplink direction (bufferbloat, combined with
upload/download interference).

We showed that (assuming the uplink is congested): 

1- sending a small amount of tiny packets (small bitrate, significant packet rate) into the uplink buffer,
they occupy the unnecessary (so to speak) buffer slots and reduce the apparent buffer size, which in turn
reduces queueing delay. The gain may be quite significant (halve the response time for instance). Do you
know many examples where sending more packets speeds things up?

2- Actually, an intense load in the downlink direction has a similar effect: many ACKs enter the uplink
buffer at times, which is enough to make it overflow and calm down uploads. This effect may explain why a
case of "bufferbloat" may not always be as bad as it could be. 

Incidentally, the paper pits popular variants of TCP against each other in various setups. 

Best regards,
Martin

_______________________________________________
(Continue reading)

Joe Touch | 20 Aug 23:31 2014
Picon

Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP


Forwarded for David Reed.

Joe (as list admin)

-------- Original Message --------
Subject: 	Re: [e2e] Once again buffer bloat and CC. Re: A Cute Story.
Or: How to talk completely at cross purposes. Re: [ih] When was Go Back
N adopted by TCP
Date: 	Wed, 20 Aug 2014 16:03:28 -0400 (EDT)
From: 	dpreed <at> reed.com
To: 	Detlef Bosau <detlef.bosau <at> web.de>, Kathleen Nichols
<nichols <at> pollere.com>
CC: 	end2end-interest <at> postel.org, "Joe Touch" <touch <at> isi.edu>

[Joe Touch - please pass this on to the e2e list if it is OK with you]

I'd like to amplify Detlef's reference to my position and approach to
end-to-end congestion management, which may or may not be the same
approach he would argue for:

To avoid/minimize end-to-end queueing delay in a shared internetwork, we 
need to change the idea that we need to create substantial queues in
order to measure the queue length we want to reduce.  This is possible,
because of a simple observation: you can detect and measure the
probability that two flows sharing a link will delay each other before
they actually do...  call this "pre-congestion avoidance".

Rather than leave that as an exercise for the reader (it's only a Knuth
[20] problem at most, but past suggestions have not been followed up,
(Continue reading)

Detlef Bosau | 20 Aug 23:09 2014
Picon

Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP

Am 20.08.2014 um 22:03 schrieb dpreed <at> reed.com:
>
> [Joe Touch - please pass this on to the e2e list if it is OK with you]
>
>  
>
> I'd like to amplify Detlef's reference to my position and approach to
> end-to-end congestion management, which may or may not be the same
> approach he would argue for:
>

What I have in mind is different in some respect - however the goals are
quite compatible,
>
>  
>
> To avoid/minimize end-to-end queueing delay in a shared internetwork,
> we need to change the idea that we need to create substantial queues
> in order to measure the queue length we want to reduce. 
>

That's what I talked about, when I argued, we would measure the wrong
parameters.

Particularly, when you refer to Raj Jain, Jain measures (in his
mathematical model) a queueing system's power in order to achieve a
workload which would allow the system to work with optimum performance.
What we actually measure is: Was the workload too large for the system
or not?

(Continue reading)


Gmane