[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: new draft on IPv6 CPE router available for review



Mikael,

What you are referring to as a "chapter", I call it a paragraph. Yes,
indeed, the second paragraph at the end of section 5.3.2 is meant for
both sections 5.3.1 and 5.3.2, but xml formatting makes it look like the
paragraph is for section 5.3.2 only. We'll see what we can do about
that.  

As for section 9, we don't plan to get into suggestions for queuing.
It's left to the CPE Router vendor to do what they want. However, if the
community would like us to add more details to this section for queuing
algorithms, we can add that. But more people have to ask for it.

Thanks.

Hemant

-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Sent: Tuesday, July 08, 2008 1:37 AM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); v6ops@ops.ietf.org
Subject: RE: new draft on IPv6 CPE router available for review

On Mon, 7 Jul 2008, Hemant Singh (shemant) wrote:

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.t
> xt

Hi,

I am happy with the writing of the first chapter of 5.3.2, but the
second chapter perhaps needs to be lifted out of 5.3.2 as it refers to
text both in 5.3.1 and 5.3.2 ? Perhaps the second chapter of 5.3.2 needs
to be 5.3.3? If indeed intended for 5.3.2, perhaps the mention of WAN
globally routable IP address is a typo?

In 9, would it make sense to also mention other queuing and marking
mechanisms? I think home users would be very much helped by other
queuing mechanisms than a few fifo queues? To my home (I use cisco
routers) I have a fairly advanced set of bandwidth reservation queues
and do fair-queue on the rest of the traffic, and this helps a lot
compared to just fifo in each queue. I would love to see this
functionality in smaller devices as well, as this would most likely help
the "I have 24/1 ADSL and when I run bittorrent and upload, my download
speeds drop)", as a more advanced queuing algorithm could prioritize TCP
ACK packets (or just small packets in general). I believe Linux already
has a lot of this, so for a vendor using embedded Linux, this would be
fairly easy to enable and recommending it in the draft might help them
in their decision to do so.

Apart from that, I am grateful that you included the unnumbered model as
an option in the draft. Thanks a lot!

Regards,

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se