Subject: RE: reliability and congestion control

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 10 Jan 2002 17:32:36 +0100

Agreed.

Hesham
  > -----Original Message-----
  > From: Ralph Droms [mailto:[email-masked]]
  > Sent: Thursday, January 10, 2002 1:39 PM
  > To: [email-masked]
  > Subject: Re: reliability and congestion control
  > 
  > 
  > "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
  > 
  > At 03:00 PM 1/9/2002 -0800, Reinaldo Penno wrote:
  > 
  > >--- Yoshihiro Ohba <[email-masked]> wrote:
  > > >
  > > > On Wed, Jan 09, 2002 at 02:22:00PM -0600, Patil
  > > > Basavaraj (NET/Dallas) wrote:
  > > > >
  > > > > 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
  > > > >
  > > >
  > > > 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.
  > >
  > >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
  > >
  > > >
  > > > 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
  > > >
  > >
  > >
  > >__________________________________________________
  > >Do You Yahoo!?
  > >Send FREE video emails in Yahoo! Mail!
  > >http://promo.yahoo.com/videomail/
  >

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Jan 2002 10:54:27 -0800 (PST)

As someone pointed out (and I agree) the discussion of
congestion control is not what protocol we shoud use
(TCP, SCTP or even the newest DCP).

In the end of the day I am trying (nad maybe others)
to get across is a more general concept. The fact is
that we should not design protocols thiking about the
best case scenario, i.e., to run only on "happy
networks", where everybody has 10/100MB at their
home/mobile, there is no contention of resources, core
speeds are NxOC-1024 and server/devices are monster
multiprocessed machines and hotstand-by elements are
everywhere.

We design protocols to be robust (up to a point of
course) in the event of failures: failures on the
device running the protocol itself, network failures,
security attacks, synchronization effects, etc.

I take pleasure to work on protocols that are still
going to be used years from now in different network
scenarios. Someone once said that you designed a good
protocol if it has good uses you never imagined. 

So, let's not change/bend the charter so early in the
game to fit this or that proposal. It seems to me
sometimes that instead of making sure the protocols
fit the charter, the charter is been modified to fit a
proposal. 

So, let's do the right thing. Let's work on the
requirements first and then analyze proposals. If
during/after writing the requirements we think we are
creating some type of frankenstein protocol we can ask
the chairs/ADs to change the charter.

my 2 cents (maybe a dollar..)

thanks,

Reinaldo