LARTC - Jun 2004 - Modems: Cable or DSL digital blunders that lartc may help with.

I have a Cable ''modem'' that has a problem that many of these
devices is
bound to have.  I was wondering what other lartc user thought about this
and if DSL has simular problems.

Cable, being Asymetrical, is able to upload at a given rate and hopefully
has a buffer, in the modem, of some kind.  When I nc(netcat) to a UDP
echo, or discard, server I get about 10Mbps out on my ethernet, but only
256Kbps acctualy receved(reported by an open echo server).  Other traffic
on the link suffers grately from this, so I don''t do it oftan :)  I use
htb to curve this and that seams to work nice.

NO REALY MY CABLE MODEM DOSEN''T MAKE ANY ATTEMPT TO, CALL FOR HELP,
CONTROL THE FLOW(aka flow-control, supported by ethernet and rs-232).

TCP workes a bit better, but not if I use more then 7 uploads at once. 
With more then 7 the rate detection, read about this on your own time,
generates more than 3(The TCP limit for ''giving up'') * 7(The
number of
connectios) of these droped/missing packets that every connection gives
up.




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

On Tuesday 22 June 2004 00:33, Mike Mestnik wrote:
> I have a Cable ''modem'' that has a problem that many of
these devices is
> bound to have.  I was wondering what other lartc user thought about this
> and if DSL has simular problems.
Was there a question in here somewhere?

<snip>
> NO REALY MY CABLE MODEM DOSEN''T MAKE ANY ATTEMPT TO, CALL FOR
HELP,
> CONTROL THE FLOW(aka flow-control, supported by ethernet and rs-232).
Okay?
> TCP workes a bit better, but not if I use more then 7 uploads at once.
> With more then 7 the rate detection, read about this on your own time,
> generates more than 3(The TCP limit for ''giving up'') *
7(The number of
> connectios) of these droped/missing packets that every connection gives
> up.
"read about this on your own time"

If you''re not going to explain the situation who do you expect is going
to
research it on their time?

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Hi Mike,
>I have a Cable ''modem'' that has a problem that many of
these devices is
>bound to have.  I was wondering what other lartc user thought about this
>and if DSL has simular problems.
>  
>
Yep, we all have this problem.  Read through LARTC, ADSL_QOS howto and 
even some recent posts to this list (which cover this in great detail)
>Cable, being Asymetrical, is able to upload at a given rate and hopefully
>has a buffer, in the modem, of some kind.  When I nc(netcat) to a UDP
>echo, or discard, server I get about 10Mbps out on my ethernet, but only
>256Kbps acctualy receved(reported by an open echo server).  Other traffic
>on the link suffers grately from this, so I don''t do it oftan :)  I
use
>htb to curve this and that seams to work nice.
>
>NO REALY MY CABLE MODEM DOSEN''T MAKE ANY ATTEMPT TO, CALL FOR HELP,
>CONTROL THE FLOW(aka flow-control, supported by ethernet and rs-232).
>  
>
There is no such flowcontrol in ethernet or rs232.  TCP only indicates 
congestion by dropping packets.  There is something called ECN, but it 
is rarely implemented (and tests suggest that it doesn''t help as much
as
theory might like).

Read the LARTC and come back for more.  It''s a really great document

Ed W

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

--- Ed Wildgoose <lists@wildgooses.com> wrote:
> Hi Mike,
> 
> >Cable, being Asymetrical, is able to upload at a given rate and
> hopefully
> >has a buffer, in the modem, of some kind.  When I nc(netcat) to a UDP
> >echo, or discard, server I get about 10Mbps out on my ethernet, but
> only
> >256Kbps acctualy receved(reported by an open echo server).  Other
> traffic
> >on the link suffers grately from this, so I don''t do it oftan
:)  I use
> >htb to curve this and that seams to work nice.
> >
> >NO REALY MY CABLE MODEM DOSEN''T MAKE ANY ATTEMPT TO, CALL FOR
HELP,
> >CONTROL THE FLOW(aka flow-control, supported by ethernet and rs-232).
> >  
> >
> 
> There is no such flowcontrol in ethernet or rs232.  TCP only indicates 
> congestion by dropping packets.  There is something called ECN, but it 
> is rarely implemented (and tests suggest that it doesn''t help as
much as
> 
> theory might like).
> 
http://www.lammertbies.nl/comm/info/RS-232_flow_control.html
ECN is software flow control.  There is also icmp for software FC?  The
idea is too prevent ''buffer underruns'' in the modem, any SNMP
or other
stats on this buffer would also provide SWFC.  

http://www.nwfusion.com/netresources/0913flow.html
This is ethernets HWFC, that any directly connected modem could use.  The
idea then is for the directly connected computer to use SwFC(ECN or
?icmp?) to pass this FC onto other hosts using the modem.
> Ed W
> 
Thanx Ed.
Mike M




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

>http://www.lammertbies.nl/comm/info/RS-232_flow_control.html
>ECN is software flow control.  There is also icmp for software FC?  The
>idea is too prevent ''buffer underruns'' in the modem, any
SNMP or other
>stats on this buffer would also provide SWFC.  
>  
>
I don''t consider this to be "flow-control" in the sense of
throttling
sending.  This is really a syncronisation protocol.
>http://www.nwfusion.com/netresources/0913flow.html
>This is ethernets HWFC, that any directly connected modem could use.  The
>idea then is for the directly connected computer to use SwFC(ECN or
>?icmp?) to pass this FC onto other hosts using the modem.
>  
>
Hmm, I wasn''t aware of a "pause" ability for ethernet.  But
still this
is a very low level layer 1 protocol.  In other words this will calm 
your 100mb net card talking to your 10mbit port on your cable modem.  
But it has no idea that the cable modem only has a 256kb link

You need something which works at IP level or above.  TCP (level higher) 
has some stuff, but (I repeat) it basically involves dropping traffic 
until the sender slows down.  There are protocols like ECN, but they are 
broadly unsupported.  ICMP stuff is frequently dropped by 
routers/firewalls making it problematic (look at how difficult it is 
just to do MTU discovery!)

What''s your question though?  Read the LARTC howto and the ADSL QOS 
howto.  They are both excellent docs.  Also read up on some basic TCP 
notes.  There is nothing really clever that you can do - it''s all in
the
docs you just have to work around the limitations of the protocols

Ed W
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

--- Ed Wildgoose <lists@wildgooses.com> wrote:
> 
> >http://www.lammertbies.nl/comm/info/RS-232_flow_control.html
> >ECN is software flow control.  There is also icmp for software FC?  The
> >idea is too prevent ''buffer underruns'' in the modem,
any SNMP or other
> >stats on this buffer would also provide SWFC.  
> >  
> >
> 
> I don''t consider this to be "flow-control" in the sense
of throttling
> sending.  This is really a syncronisation protocol.
> 
Yes, SwFC is lame.  Howerver it would be a good band-aid, to have router
and modem syncronisation take place.
> >http://www.nwfusion.com/netresources/0913flow.html
> >This is ethernets HWFC, that any directly connected modem could use. 
> The
> >idea then is for the directly connected computer to use SwFC(ECN or
> >?icmp?) to pass this FC onto other hosts using the modem.
> >  
> >
> 
> Hmm, I wasn''t aware of a "pause" ability for ethernet. 
But still this
> is a very low level layer 1 protocol.  In other words this will calm 
> your 100mb net card talking to your 10mbit port on your cable modem.  
> But it has no idea that the cable modem only has a 256kb link
> 
The router(PC) has no idea of the buffer fullness, this is the underlying
problem!  The cable modem needs to triger a "pause" when it''s
buffer
reaches %80 full, regardless of any other rate limiting.  Linux kernel can
do this with some cards, under heavy CPU strain(htb).

CONFIG_NET_HW_FLOWCONTROL: net/Kconfig
> You need something which works at IP level or above.  TCP (level higher)
> 
No, the DEVICE is not > layer 3.  It''s simply a bridge, with a
stoplight
on one end.  The idea is to not make any cars crash, that has nothing todo
with the ball game a car might want to get too.
> has some stuff, but (I repeat) it basically involves dropping traffic 
> until the sender slows down.  There are protocols like ECN, but they are
> 
Yes, ECN will/should be used for routers attached to bridges.
> broadly unsupported.  ICMP stuff is frequently dropped by 
> routers/firewalls making it problematic (look at how difficult it is 
> just to do MTU discovery!)
> 
ECN makes this a non-issue.
> What''s your question though?  Read the LARTC howto and the ADSL
QOS
> howto.  They are both excellent docs.  Also read up on some basic TCP 
> notes.  There is nothing really clever that you can do - it''s all
in the
> 
> docs you just have to work around the limitations of the protocols
> 
I would like to know is maby a ?$6000.00? Cisco cable mobem will not only
use HwFC but ECN as well?  Thought i''d like to find a $150.00 modem
that
will just do HwFC, maby an internal one?
> Ed W
> 


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

>Yes, SwFC is lame.  Howerver it would be a good band-aid, to have router
>and modem syncronisation take place.
>  
>
You have got to consider that some devices are asynchronous and some are 
synchronous
>The router(PC) has no idea of the buffer fullness, this is the underlying
>problem!  The cable modem needs to triger a "pause" when
it''s buffer
>reaches %80 full, regardless of any other rate limiting.  Linux kernel can
>do this with some cards, under heavy CPU strain(htb).
>
>CONFIG_NET_HW_FLOWCONTROL: net/Kconfig
>  
>
Possibly, but this doesn''t help you that much.  If your http download
is
whacking out packets then your SSH session will still effectively get 
crowded out.

You want something to queue for a bit and prioritise this extra traffic.

...you have read the LARTC Howto haven''t you?
>>You need something which works at IP level or above.  TCP (level higher)
>>    
>>
>No, the DEVICE is not > layer 3.  It''s simply a bridge, with a
stoplight
>on one end.  The idea is to not make any cars crash, that has nothing todo
>with the ball game a car might want to get too.
>  
>
??

>Yes, ECN will/should be used for routers attached to bridges.
>  
>
Not as far as I am aware? (today)

>>broadly unsupported.  ICMP stuff is frequently dropped by 
>>routers/firewalls making it problematic (look at how difficult it is 
>>just to do MTU discovery!)
>>
>>    
>>
>ECN makes this a non-issue.
>  
>
??? Eh?
>>What''s your question though?  Read the LARTC howto and the ADSL
QOS
>>howto.  They are both excellent docs.  Also read up on some basic TCP 
>>notes.  There is nothing really clever that you can do - it''s
all in the
>>
>>docs you just have to work around the limitations of the protocols
>>
>>    
>>
>I would like to know is maby a ?$6000.00? Cisco cable mobem will not only
>use HwFC but ECN as well?  Thought i''d like to find a $150.00 modem
that
>will just do HwFC, maby an internal one?
>  
>
No it won''t.  Well, even if it did, I don''t think it would
help.  Unless
the rest of the world understands your protocol then you will still have 
problems with incoming connections.

You can get a £250 cisco adsl modem which looks rather powerful.  Try 
that if you want to experiment.

Please, please read the LARTC-Howto and ADSL-qos howto.  I think it has 
everything that you need.
>  
>
>>Ed W
>>
>>    
>>
>
>
>
>		
>__________________________________
>Do you Yahoo!?
>New and Improved Yahoo! Mail - Send 10MB messages!
>http://promotions.yahoo.com/new_mail 
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>  
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Hello,

My name is Adam and I try to get PQ by means of CBQ. Sorry for writing about
such a problems but I struggle with this for 2 weeks .. I have searched the
LARTC archive till 2000 and everyone say using priorities lowers delay.. but
it does NOT.

I can NOT see ANY difference when using priorities in CBQ (especially from
the delay point of view!!!!!!!!) - in comparioson to CBQ witohout
priorities. I did dozens of tests and CBQ and for packets less than 512
bytes delay is saw tooth chart changing (oscillating) from less than 1ms to
8ms periodically. .

Is there something wrong with my configuration???

My configuration is like this:

link bandwidth:
	2Mbps

2 queues:
	priority - bounded to 200kbps
	best effort - at least 1.3Mbps (+ the rest of the link that is unused)

traffic generated:
	priority - ca. 200kbps but less than (periodic, for different packet sizes
but rate constant: 96,128,256,512Bytes)
	best effort - 2Mbps (periodic, 1000Bytes packets)

	(so the summ of both flows is always MORE that link bandwidth which is
2Mbps)

My configuration is like this:

# Root
tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit avpkt 1000 cell
8 mpu 1500

# Main Class
tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate
1000kbit maxburst 10 allot 1000 cell 8 avpkt 1000 bounded isolated
# Prio
tc class add dev eth0 parent 1:1 classid 1:2 cbq bandwidth 100Mbit rate
100Kbit  weight 10Kbit  prio 1 allot 1000 cell 8 maxburst 10 avpkt 1000
# Best effort
tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit rate
650Kbit weight 65Kbit prio 2 allot 1000 cell 8 maxburst 10 avpkt 1000

#IPv4 filters
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip src
192.168.2.2 classid 1:2
tc filter add dev eth0 parent 1:0 protocol ip prio 3 u32 match ip src
192.168.3.2 classid 1:3

please tell me if the weight parameter can mess with prio value?

regards

adam

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Yes, I do understand the LARTC and wondershaper.  As for ADSL-qos I
didn''t, but I did read all the TCP rfcs regarding packet lose and
throughput negotiation, ect.

--- Ed Wildgoose <lists@wildgooses.com> wrote:
> 
> >Yes, SwFC is lame.  Howerver it would be a good band-aid, to have
> router
> >and modem syncronisation take place.
> >  
> >
> 
> You have got to consider that some devices are asynchronous and some are
> 
> synchronous
> 
I don''t follow you?  The router would never tell the modem to stop the
downward, exept for the rare cases where you need HW_FLOWCONTROL.  As for
upward that has the most problems where moving to a slower bandwith.
> >The router(PC) has no idea of the buffer fullness, this is the
> underlying
> >problem!  The cable modem needs to triger a "pause" when
it''s buffer
> >reaches %80 full, regardless of any other rate limiting.  Linux kernel
> can
> >do this with some cards, under heavy CPU strain(htb).
> >
> >CONFIG_NET_HW_FLOWCONTROL: net/Kconfig
> >  
> >
> 
> Possibly, but this doesn''t help you that much.  If your http
download is
> 
> whacking out packets then your SSH session will still effectively get 
> crowded out.
> 
> You want something to queue for a bit and prioritise this extra traffic.
> 
> ....you have read the LARTC Howto haven''t you?
> 
This is where tos comes into play.
Most users won''t need much more then pfifo_fast with a 3 second fifo
buffer in the modem.  Keep in mind we only use the modem''s fifo buffer
for
overflow(%20 to %80).
> >>You need something which works at IP level or above.  TCP (level
> higher)
> >>    
> >>
> >No, the DEVICE is not > layer 3.  It''s simply a bridge,
with a
> stoplight
> >on one end.  The idea is to not make any cars crash, that has nothing
> todo
> >with the ball game a car might want to get too.
> >  
> >
> ??
The DEVICE is a modem, like a serial v.34, ect.  It''s a bit of hardware
and some modulation protocol.  So there''s no need for it to work with
the
upper layers.  It''s sufficent for the device to use it''s
?ethernet/USB?
line to signal a pause when it''s gettting congested.

This means that any router attached to it is responsible for carrying out
the upper layers flow control(ECN).
> 
> 
> >Yes, ECN will/should be used for routers attached to bridges.
> >  
> >
> 
> Not as far as I am aware? (today)
This was my next question, dose htb or tbf effect linuxes ECN?  Directly
or indirectly?
> 
> 
> >>broadly unsupported.  ICMP stuff is frequently dropped by 
> >>routers/firewalls making it problematic (look at how difficult it
is
> >>just to do MTU discovery!)
> >>
> >>    
> >>
> >ECN makes this a non-issue.
> >  
> >
> 
> ??? Eh?
ECN like IPv6 fixes some of the short commings in current technology.

For non-ECN connections droping one packet will signal a leveling of
bandwith(TC-SFQ).  If a TCP conection loses 3 packets, regardless of what
router droped each, it''s bandwith is cut in half.  It would be nice to
add
a droped packet monitor to linux''s connection tracking and feed this
into
sfq.
> 
> >>What''s your question though?  Read the LARTC howto and the
ADSL QOS
> >>howto.  They are both excellent docs.  Also read up on some basic
TCP
> >>notes.  There is nothing really clever that you can do -
it''s all in
> the
> >>
> >>docs you just have to work around the limitations of the protocols
> >>
> >>    
> >>
> >I would like to know is maby a ?$6000.00? Cisco cable mobem will not
> only
> >use HwFC but ECN as well?  Thought i''d like to find a $150.00
modem
> that
> >will just do HwFC, maby an internal one?
> >  
> >
> 
> No it won''t.  Well, even if it did, I don''t think it
would help.  Unless
> 
> the rest of the world understands your protocol then you will still have
> 
> problems with incoming connections.
> 
It''s only a hardware flow control for a directly connected modem? 
There
is no software protocol, exept ECN and TCP.

That''s what I''m saying is that the rest of the world FAILED to
read about
the ethernet standered and implement it correctly.  Even thought it''s
clearly documented in the linux kernel how to implement.
> You can get a 250 cisco adsl modem which looks rather powerful.  Try 
> that if you want to experiment.
> 
I have looked at cisco cable modems.  I would hope that thay would not
only have proper flow control, including ECN, but also have a big buffer
with lots of TC.  However they are out of my price range.
> Please, please read the LARTC-Howto and ADSL-qos howto.  I think it has 
> everything that you need.
> 
> >  
> >
> >>Ed W
> >>
> >>    
> >>


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Ed Wildgoose <lists@wildgooses.com> writes:
> You need something which works at IP level or above.  TCP (level higher)
has
> some stuff, but (I repeat) it basically involves dropping traffic until the
> sender slows down.  There are protocols like ECN, but they are broadly
> unsupported.  ICMP stuff is frequently dropped by routers/firewalls making
it
> problematic (look at how difficult it is just to do MTU discovery!)
ECN is largely there so that *non*-TCP protocols can implement congestion
control like TCP does.

The problem that was observed in DRUMS was that UDP based protocols like the
various streaming audio/video protocols that have cropped up in recent years
would push any TCP streams out of their way. Routers would drop UDP packets
but most of them didn''t throttle their bandwidth on dropped packets.
And
congestion control using dropped packets required every protocol to implement
its own acknowledgement and windowing infrastructure. The goal was to have
something simple that could be supported at a lower level.

ECN on TCP connections is a bit superfluous. It could be used to throttle the
bandwidth being used before it led to dropped packets, but it''s unclear
that
would help any. Traditional TCP congestion control is fairly effective at
grabbing all the available bandwidth anyways. ECN would be accomplishing
largely the same thing that RED accomplishes at much greater expense on the
router.

Incidentally, ICMP Source Quench turned out to be a bad idea. Modern RFCs say
hosts "SHOULD NOT" send them. The problem is that responding to
congestion by
sending more packets exacerbates the congestion.


-- 
greg

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

--- Greg Stark <gsstark@mit.edu> wrote:
> 
> Ed Wildgoose <lists@wildgooses.com> writes:
> 
> > You need something which works at IP level or above.  TCP (level
> higher) has
> > some stuff, but (I repeat) it basically involves dropping traffic
> until the
> > sender slows down.  There are protocols like ECN, but they are broadly
> > unsupported.  ICMP stuff is frequently dropped by routers/firewalls
> making it
> > problematic (look at how difficult it is just to do MTU discovery!)
> 
> ECN is largely there so that *non*-TCP protocols can implement
> congestion
> control like TCP does.
> 
> The problem that was observed in DRUMS was that UDP based protocols like
> the
> various streaming audio/video protocols that have cropped up in recent
> years
> would push any TCP streams out of their way. Routers would drop UDP
> packets
> but most of them didn''t throttle their bandwidth on dropped
packets. And
> congestion control using dropped packets required every protocol to
> implement
> its own acknowledgement and windowing infrastructure. The goal was to
> have
> something simple that could be supported at a lower level.
> 
The problem is data in general, both UDP and TCP.  Thought most ppl only
have one computer connected to there modem, so high level protocols like
ECN are overkill.  I therefor recomend that any vendor that creates modems
make sure they incoperate flow controle on ALL there inbound traffic.
> ECN on TCP connections is a bit superfluous. It could be used to
> throttle the
> bandwidth being used before it led to dropped packets, but it''s
unclear
> that
> would help any. Traditional TCP congestion control is fairly effective
> at
> grabbing all the available bandwidth anyways. ECN would be accomplishing
> largely the same thing that RED accomplishes at much greater expense on
> the
> router.
> 
> Incidentally, ICMP Source Quench turned out to be a bad idea. Modern
> RFCs say
> hosts "SHOULD NOT" send them. The problem is that responding to
> congestion by
> sending more packets exacerbates the congestion.
> 
What about ICMP TTL Expier?  Also ECN''s data WILL have the same effect?
thought I know it''s validated that both sides of the connection support
ECN.  When EVERY one is using it there will be the same type of traffic
flow for the congestion state.
> 
> -- 
> greg
> 
> 


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/