Subject: Re: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request]

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Fri, 8 Nov 2002 21:31:20 -0600

> During that day, a few content providers had problems delivering
> all the requested content. In at least some cases, this was server
> overload. However, careful analysis of traffic logs by large ISPs
> afterwards confirms that the Internet performed brilliantly. Despite
> fibre cuts in lower Manhatten and numerous environmental problems at
> Hudson Street, the Internet automatically re-routed around the damage
> and kept going. And the large ISPs did NOT (repeat did NOT) start
> dropping packets because of the cut fibres -- their backbones were
> carefully over-engineered so the traffic was re-routed around the
> lost links.

 This is a comment from a service provider.
 "BGP stability was normal that day, or even better than normal since 
many companies sent their workers home (so there were probably fewer 
configuration changes on the 11th than on other days).  I've heard 
anecdotally that some backbone networks saw a decrease in traffic 
(probably because people were at home on low-bandwidth connections 
or watching TV, or were thwarted in their attempts to access to popular 
news sites)."
( other than cowie's presentation on 9/11)

But, we should also remember that telephone networks are the major
ones to be affected. One of the major reason for the robustness of 
Internet is the redundancy among ISP ( which is not the case in 
PSTN network.) In NY area, verizon was the hot spot/congestion point
as all carriers junction at verizon. 
(Note: I searched for NY article for refernce but couldn't find
 one.. Possibly, some nanoger can point, as it came under discussion.)

> 
> Access to the US NASA feeds of the mars lander landing was a bigger
> problem in Internet terms, yet even then the problems were on NASA's
> access links and its servers, rather than in any large ISPs network.

But, Code RED had major effect on the routing system than the above one..

> To give  another example, there was a fibre cut near 
> Baltimore a while back. It cut several fibre bundles from different 
> carriers. The IP  routing system
> just automatically detected the link-down state and routed 
> around the cut links
> -- and there was enough spare capacity in the other links 
> that there was no significant loss of service.

Although, I accept your point about reconvergence, fiber cut due
to Baltimore train wreck had some major effect partly. Since,
it is a train wreck, telecommunication repairs took some extra
time to repair than normal. 

http://www.cs.berkeley.edu/~randy/Courses/cs294.s02/baltimore_train-071901.doc
( Sorry for the word Doc ref. I could not find archives in Keynote/traffic
health site)

> The IP  routing system
> just automatically detected the link-down state and routed 
> around the cut links
> -- and there was enough spare capacity in the other links 
> that there was no significant loss of service.

A network can become overloaded for three reasons: Unexpected and major event 
leading to simultaneously access of the network,Link/router failures/outages 
and  Asymmetry at various levels. Of all this, link failures due to fiber
cut is a major contributor. So, a measurement study on them will be 
really useful.

Although, failure analysis in BGP was well studied by Ahuja/labovitz, it was
not done for intra-domain(link state) network ( as reconvergence time is less
when compared to inter-domain.) But It is necessary to study them, both for
helping researchers/operators.

- "Service availability" is a common term in telephone networks. But, with
the advent of VoIP/ priority traffic, it is necessary to define service
availability in Internet too. For doing such things, failure modeling is
the base step ( studying rate/CDF of failures etc.)
( It will help operators to define terms for SLA )

- Learning Objective functions for OSPF weight optimization
  ( helps researchers/operators)

> It would also be helpful if going forward we could clearly 
> separate our
> sundry concerns into the different layers of the Internet 
> Architecture (Physical,
> Link, IP, Transport, Application).

This is very important for this group.. 
For example:
 - when your talking about Japan-IAA system ..It is application
layer and IETF has nothing to say about a data base unless they
want to load balance like content distribution networks.

- Recently, alternate routing - In application layer, it is 
feasible (TRIP ) but in Network layer, not possible in near future.

But, once the SIP requirement was shipped to Sipping group, we should
only be talking in network layer realm.

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

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 9 Nov 2002 08:02:50 -0500

On Friday, Nov 8, 2002, at 22:31 America/Montreal, Ayyasamy, 
> as all carriers junction at verizon.

Hmm.  Not sure what you mean by "carriers" and what you mean by 
"verizon".
"carrier" could mean either telephone company or ISP given the preceding
text.  Verizon is a firm, not a location.

There are several ISP interconnects in lower Manhatten.  The most
significant one is on Hudson Street, but others do exist.

> But, Code RED had major effect on the routing system than the above 

That impact varied directly with (1) which firm's routers one had 
installed
and (2) one's configuration for those routers.  Folks with 
hardware-based
ACLs didn't have big problems.  Folks using CPU-based ACLs had problems,
because the CPU became over-burdened.  This is not a systemic issue or
a protocol issue, but rather an equipment selection/deployment issue.

> helping researchers/operators.

	Inside an ISP, I-BGP is used internally in addition to an IGP -- and 
I-BGP
is more significant to the convergence of the routing system as 
perceived
by customers/users.

> ( It will help operators to define terms for SLA )

	Several operators have defined both "service availability" and "SLA".
The current definitions vary among carriers.  Customers who don't read
their SLAs closely might be disappointed by what the SLAs actually 
promise.

>   ( helps researchers/operators)

Not clear what you mean by "Learning Objective functions".

> want to load balance like content distribution networks.

"Voice over IP" and "SIP" are also examples of application-layer 
services.

> feasible (TRIP ) but in Network layer, not possible in near future.

I do not understand your meaning.

> only be talking in network layer realm.

I would not object to that proposal.

	As Ken explains much better than I do, the reason there are 2 separate
documents is to separate issues architecturally.  His 
draft-carlberg-ets-general-*
is focused on concerns relating to the IP-layer, while 
draft-carlberg-ets-telephony-*
is focused on concerns relating to VoIP applications (at the 
application-layer).

	Clearly some folks will want to use IEprep for VoIP stuff, so having 
that
documented is helpful.  However, other folks will not want to use IEprep
for VoIP, so the VoIP-related stuff needs to be separated out cleanly 
from
generic IEprep stuff.

	And it would still help if we could get more specific, clear 
documentation
on the GETS-like or IEprep-like services in use or contemplated for use 
in
countries other than US and JP.  This needs to come from folks in the 
relevant
country, rather than being claims by person in country X about country 
Y's
needs.

Ran
[email-masked]

---

From: Ken Carlberg <[email-masked]>
Date: Sat, 09 Nov 2002 18:30:12 +0000

just a small nit.

> is focused on concerns relating to VoIP applications (at the 

I would rephrase this just to say that the former can apply to the
network and application layers since no further qualifiers to
'signaling' and 'labels' are mentioned int ets-general.

> And it would still help if we could get more specific, clear documentation
> on the GETS-like or IEprep-like services in use or contemplated for use in
> relevant country, rather than being claims by person in country X about 
> country Y's needs.

an attempt has been made to do this with the Framework document with 
respect
to the system in use by the UK.  In addition, its been reviewed by the UK 
govt (ie, the customer/user of the service) and this review has been 
acknowledged in the draft.  I think think this is one appropriate approach 
to take

-ken