Subject: RE: reliability and congestion control

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 9 Jan 2002 14:22:00 -0600

Yoshihiro Ohba [[email-masked]] wrote:
>If underestimating the suggested requirements in the charter will not
>result in affecting the performance of *end-to-end* data traffic 
>on the access network, it would be okay.  

It is very unlikely that the performance of *end-to-end* data traffic
will be seriously affected by performing network access messaging.
Network
access messaging occurs at:
1. Startup - When there is no e2e traffic yet and the user
   device/terminal is requesting network connectivity
2. Timer Expiry - If the access network requires that the user device
   provide authentication data on an intermittent basis (timers), it
   may cause a "minor" impact on the e2e traffic that may be ongoing
   at the time that the device would need to send auth data. However
   if you limit the number and size of these messages, there should
   not be a serious impact on e2e data traffic 
3. The network may also optionally challenge the user device
   randomly. But the same argument (above in 2) holds good.

>For me, it does not look 
>like an overkill yet, but I may be too conservative.

Maybe you have some scenarios in mind that I may be
overlooking. If you do include this as a reqiurement for PANA,
hopefully the requirements I-D will have some justification.

>Yoshihiro Ohba

-Basavaraj

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 9 Jan 2002 17:11:45 -0500

> hopefully the requirements I-D will have some justification.

Yes, I have some scenario in mind as you anticipate. :-)

As you pointed out, the frequency of the PANA messaging would not be
so large.  However, when we talk about congestion, we should also
consider the amount of information exchanged during PANA messaging.

For example, according to RFC 2716 (EAP-TLS), a single TLS record may
be up to 16384 octets in length, but a TLS message may span multiple
TLS records, and a TLS certificate message may in principle be as long
as 16MB.  RFC 2716 discuss it only from the viewpoin of fragmentation,
but such a lengthy message would also raise the issue of congestion
control.

So, it may not be very unlikely that the performance of *end-to-end*
data traffic will be seriously affected by performing network access
messaging.

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 9 Jan 2002 15:00:27 -0800 (PST)

> consider the amount of information exchanged during

Even other things need to be accounted for.

First, they might not be frequent per sub but there
can be lots of them. In a broadband access scenario
people usually stay connected for a long time, but in
dial-up (wireline and maybe wireless?) this is not
true.

I looked at some statistics from big dial-up ISP some
hours ago and it had >60 authentications requests per
second in the Radius Proxy.  

Second there might be subsequent authentications
during the life of the "master" connection where you
change your service package or want to see premium
content (this already happens today). 

Then there is also the failure case. What happens when
an big aggregation box goes down taking out thousands
of subs? Their modem/router/PC will probably come back
at more or less the same time overloading the PAA
server. 

This actually happened years ago to a high speed
provider when after the aggregation box rebooted all
the PCs behind DSL routers started sending DHCP
requests at the same time overloading the DHCP server.

thanks,

Reinaldo 

> performing network access

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: Ralph Droms <[email-masked]>
Date: Thu, 10 Jan 2002 07:38:32 -0500

"Congestion control" includes more than controlling the effect of multiple 
packets in a single flow.  As pointed out below, simultaneous transmission 
from multiple sources - e.g., because of synchronization at startup time or 
becuase of element failure - can also cause congestion.  Techniques like 
delayed initialization and exponential backoff fall under the category of 
"congestion control", and congestion control should be a requirement of any 
PANA protocols.

- Ralph