Subject: [Adslmib] coments on draft G.SHDSL.BIS MIB

From: [email-masked]
Date: Mon, 12 Apr 2004 09:33:21 -0500

Thank you Clay for taking on the editorship of G.SHDSL.BIS.
My comments are below.

Reference this paragraph:

> 2.3.2.   Changes to Line Rate Objects
>
>  Four objects in the HDSL2/SHDSL Line MIB have rate limitations.
>   In each case, these objects have the syntax
>
>        SYNTAX      Unsigned32(0..4112000)
>
>   Changes introduced in G.SHDSL.bis support an increased upper rate
>   of 5696 kbits/s, leading to the updated syntax
>
>        SYNTAX      Unsigned32(0..5696000).

Comments:

I think the original RFC3276 was incorrect with respect to the maximum line
rate for 2 pairs.
A single G.SHDSL pair may have a line rate up to 2312000 bps.  With two
pairs, doubling that amount
would be 4624000.  I think RFC3276 incorrectly doubled the value of
(2048000 + 8000) to get 4112000.

Now, with 4 wire pairs, it seems correct to have 2312000 * 4,  or 9248000
as the maximum line rate.
Am I missing something ?  Is there something I don't understand about the
5696000 number ?

I also think the defaults should follow G.SHDSL instead of HDSL2.
The default for hdsl2ShdslSpanConfMinLineRate would be 200000 (192000 +
8000).
And the default for hdsl2ShdslSpanConfMaxLineRate would be 2312000.

Also, I think a status parameter with the data rate or effective bandwidth
of the span would
be useful.  The maximum data rate would be (2312000 - 8000) * 4, or
9216000.

hdsl2ShdslStatusActualDataRate OBJECT-TYPE
           SYNTAX      Unsigned32(0..9216000)
           UNITS       "bps"
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
           "Contains the actual data rate for this HDSL2/SHDSL span. "

       ::= { hdsl2ShdslSpanStatusEntry xxx }

Comments ?

Lee Nipper
Verilink Corporation

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Clay Sikes" <[email-masked]>
Date: Tue, 13 Apr 2004 05:52:51 -0400

Lee,

Thanks for your comments.

I need to study the rates a little closer as I don't feel I currently 
have a good understanding of  the values. I should be able to respond in 
a few days.

Thanks,
Clay Sikes

>       ::= { hdsl2ShdslSpanStatusEntry xxx }

-- Paradyne Mail --

---

From: "Clay Sikes" <[email-masked]>
Date: Tue, 13 Apr 2004 18:32:24 -0400

Hi Lee,

I looked over the the ITU-T G992.1 (12/2003), talked to a few folks, and 
possibly developed a better understanding. Hopefully, someone will 
correct me if I'm  in error.

The user (payload) data rates come from the formula ( n x 64) + ( i x 8 
) kbits/s for a two-wire pair. The maximum user (payload) for a single 
pare will occur as specified in Annex F when when operating in  
32-TCPAM. In this mode, n = 89 and i = 0 giving a user data rate of 5696 
kbits/s. Also, there is an addition framing overhead of 8 kbits/s so the 
"line rate" would be 5696 kbits/s + 8 kbits/s which give us 5704 kbits/s 
on a single pair. In multi-pair mode, each pair will have the 8 kbits/s 
framing overhead. Now up to 4 pairs or 8 wires are supported. So in the 
case where we have all 4 pairs running at the maximum rate, we get a 
line rate of  4 x (5696 kbits/s + 8 kbits/s) = 4 x 5705 kbits/s = 22 816 
kbits/s. This would  indicate, if my logic is correct, that the max line 
rate for the MIB objects needs to change from 5696000 to  22816000. Does 
this sound right?  Also, it might be a good idea to modify the 
description for the line rates to clearly state that this rate is user 
(payload) and framing overhead. How does that sound.

Annex G worries me because it seems provisional as data rates are 
specified from 2320 to **max rate** kbits/s. I would hope that we would 
have to have frequent changes for max rates. But then again, it would be 
good practice.  :-)

Given, the MIB objects refer to line rate which include both user 
(payload) and framing, it might be a good idea to add a read-only object 
to the hdsl2ShdslSpanStatusTable that subtracts off the framing overhead 
for each of the pairs so a user can clearly see their payload data rate. 
Would anyone object to adding an object for this?

I'm not clear on exactly where you are getting the numbers for a new 
default line rate. I wonder if changing a default value would cause a 
problem any current implementations. Personally in most of the products 
I have worked on, we user our own default values and consider that which 
is defined in the MIB to only be a suggestion. ;-)
Perhaps someone can chime in on the idea of a change of default.

This is my understanding. Please correct me if I got this wrong.

Regards,
Clay Sikes

Clay Sikes wrote:

> have a good understanding of  the values. I should be able to respond 
> in a few days.
>
> Thanks,
> Clay Sikes
>

-- Paradyne Mail --

---

From: Bob Ray <[email-masked]>
Date: Wed, 14 Apr 2004 09:15:44 -0500

Maybe we need to reevaluate the option of refreshing
RFC3276 instead of having a g.shdsl.bis draft...

One thing we might try to do is to get rid of the range
on the line speed objects, and perhaps open up the wire 
pair...  

Thoughts?  

-- 
Bob Ray <[email-masked]>

---

From: Rajesh Abbi <[email-masked]>
Date: Wed, 14 Apr 2004 10:45:51 -0400

If the only issue to address is the rate limitation, then I
support Bob's suggestion to get rid of the rate ranges and
leave it flexible for future rate enhancements.

-Rajesh