Subject: RE: [Ieprep] Re: PSTN collapse

From: "Gunn, Janet" <[email-masked]>
Date: Tue, 10 Dec 2002 10:55:39 -0500

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]

 As various people have been 
noting,
there were particular access links that were cut or congested, but that 
is
a separate issue. 

[JPG] I don't think that is "a separate issue".  I think that is the most
pressing part of the overall issue IEPREP is supposed to be addressing. (

[JPG] I don't think it is useful to be debating the different kinds of
"collapse" in the circuit switched vs. packet switched networks.  I agree
that it is important to understand how they are different.  But the "my
network is better than your network" doesn't help.  That being said, I am
sorry, but I can't resist adding my 2 cents.  Sometime in the last decade I
was consulting with the IT department of a university in California.  One of
the tangents of the project was to look at whether it would be a good time
to consider migrating from the PBX to VoIP.  One of the  arguments against
VoIP on the campus then was "In the last earthquake, the LAN went down, but
I still had dial tone on the PBX".

[JPG] Again, we come back to "the last mile".

IP has packets, and does not have "calls" so there is no concept in IP
of "call completion".  

[JPG] If you mean the IP protocol by itself, OK.  But the term "IP" is often
used to apply to the entire protocol suite (IP, UDP, TCP, RTP, SIP, etc.),
and some parts of the protocol suite DO have "calls".

because "rough consensus" is required to make progress in IETF (and we
don't have rough consensus right now on what issues this group ought to 
focus on).

[JPG] Maybe I am being naive, but it looks to me as if we have "rough
consensus" that "access and gateways" are the issues the group should focus
on.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 10 Dec 2002 15:45:20 -0500

> pressing part of the overall issue IEPREP is supposed to be 

Well, at least Mike Pierce seems to think that IEprep is solving the
non-problem of congestion in the core and does not seem to think that
the various approaches to access link congestion are relevant.

> and some parts of the protocol suite DO have "calls".

Hmm.  Your definition of "calls" isn't clear to me.
Clarity would help.

UDP is connectionless, so it probably is not what you mean.
TCP and SCTP have connection state, so might be what you mean.
RTP runs on UDP but does have some session state within RTP.
SIP clearly has the concept of a phone call.

Part of the challenge is that *routers* are IP-layer devices, not
(for example) SIP or RTP or TCP devices.  So the router, which is
the widget controlling which packets go where, which packets are
queued within the router using what queuing discipline, and which
packets get dropped if there were an overload, does not have the
concept of a "call".  So it isn't clear to me how one can apply
the concept of "call" to preferential packet handling.

Applying the concept of "call" to stuff implemented within SIP
(and not reaching down below the application layer) has seemed
straight-forward (to me at least).  I think this portion of stuff
has been addressed by Henning's document, but maybe I misunderstood.

> consensus" that "access and gateways" are the issues the group should 

Certainly, I'd agree we should focus on individual access links,
not the core, and not inter-domain QoS, but others here have been
taking issue with that notion.

I am unclear what you mean by "gateways", since some folks might
mean a "SIP gateway", others might mean some kind of middle-box,
others might mean "IP router", and there might be other definitions
that I haven't imagined.

Ran
[email-masked]