Subject: [Ieprep] ieprep Atlanta meeting minutes

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 22 Nov 2002 20:01:48 -0500

18-Novmber-2002, 1530 
IEPrep meeting in Salon B 
Kimberly King and Scott Bradner chairing 

Agenda Review - Chairs 

ISP Backbone of Today - Ran Atkinson 
[James Polk made the point that disparaging information sources is not
helpful.  Ran indicated that the people who reviewed his slides were mostly
in the room and that he was not claiming to represent them and accepted
potential errors as his own.]
Several points from the ISP presentation:
The description is of common properties, not of any specific ISP. 
Many operators have a prime directive to NEVER drop a packet.
Traffic exchanged according to business agreements.
Enabling QoS can cause packets to receive worse treatment.

Comments/Questions from the audience:
After some packet loss statistics were quoted, Janet Gunn asked about packet
loss due to Virus' as distinct from no loss due to cable cuts; she was told
there was no available answer.
Brian Carpenter noted that Diffserv was designed to allow diffserv in the
fast path.

David Meyer presented "Sprint & CoS" 
The slides included:
What Sprint is doing - Edge QoS using egress (to the customer) access
control lists (ACLs), not ToS bits.  (Avoiding ToS bits for this
functionality ensures they don't have to remark other packets entering the
network from Internet connections, for example.)  One possible exception
(perhaps) is for IPSec protected VPNs.
David noted their core traffic (trunks at or over OC48) is uncorrelated,
meaning it does not exhibit self-similar behavior.  (Thus they may be more
confident that traffic loads over their core is smoother and hence feel more
confident that sufficient capacity is available even during times of what
might be considered a surge.)
Their backbone has been measured to handle VoIP at 90 grade MoS (R factor?),
better than PSTN. 

Comments/Questions from the audience:
Dave Oran asked what happens in a major disaster. Dave Meyer indicated that
even in the loss of large numbers of fibers, there was no effect on
services. 
Peter Lothberg commented that internal topologies are even more complex (and
therefore more diverse with additional capacity) than portrayed in Ran's
slides.  He also emphasized customer management of the customer egress
traffic treatment and that ISPs generally do not control customer egress
traffic.  Meanwhile, customers "don't worry about the backbone." 
Susan Harris(?) asked about the meaning of "uncorrelated".  Dave responded
clarifying the effect of aggregation and smoothing at high speeds. Rohan
Mahy paraphrased saying that burstiness is dampened.
Henning Schulzrinne hypothesized it was possible that so much damage could
be caused that the network would actually operate at or over the viable
range.
Mike St. Johns asked about the factors that caused the 90 grade on the MoS
score (rather than 100) and asked about whether truly pathological traffic
behavior had been exhibited. Dave Meyer said he had not seen any. 
Pat Cain from Genuity talked about their recently offered QOS service.  This
is again an edge service on the local access link only.  The purpose is to
manage capacity of narrow pipes. He noted that core congestion is generally
self-inflicted although very large customers connections (e.g., those
connecting with OC-48) can cause some difficulty.

The next presentation "PCH; VoIP experience" was by Bill Woodcock. 
They offer VoIP from end nodes, often on narrow pipes.  A demonstration of a
VoIP call was established between an VoIP phone sitting in front of Scott
Bradner and one in Nairobi, Kenya.  Local PTT quality in Nairobi is much
worse than VoIP. NAT was (and is) a problem for VoIP.

Questions/Comments from the audience:
Kathy Nichols - One of the cite article authors also does use QoS 
Sally Floyd mentioned the current time in Kenya and wondered how many
concurrent TCP connections were occurring over the last mile.
The discussion of current circumstances are highly provisioned and Henning
Schulzrinne commenting that we need to be careful about generalizing the
current circumstances to true disaster utilization and effects. 
Ran Atkinson indicated that they could lose almost any capacity and deliver
service to what remained connected.
Peter Lothberg commented that if you really had that bad an outage, other
things would break that would have far more serious effects.  He also
believes if we have "important traffic" and "normal traffic" then important
traffic must be authenticated if it is to be given priority.  Such a
function requires crypto checksums, timestamps and the capability to check
its validity at line rate.  This then involves solving key management, and
to traverse several jurisdictions, each packet has to carry multiple such
headers.  Without inventing a way to do this, any priority mechanism is just
opening up another attack vector for the 'bad boys'. 
Pat Cain suggested that we need a lot of other things separate from the QoS
issues, and we need to spend cycles on that.

Hal Folts presented "IEPrep Requirements"
draft-ietf-ieprep-requirements-01.txt 
Hal said:
The draft is about Objectives for emergency communication using IP
technology.
Not all the objectives may be simultaneously possible, lets see what we can
do. 
He would like any place / any time access a by authorized emergency users. 
Want preferential treatment for emergency communication 
[Scott Bradner asked if what was being requested was for emergency workers
to be able to plug into any jack anywhere, authenticate themselves, and
receive preferential treatment.  Hal indicated this was desirable.]
The draft objectives also request international / interconnected service 
SLAs are relevant to this 
Request for security capabilities 
Keep the connection up, even in DoS situations 
Hal ended by asking how to move forward.

Questions/Comments from the audience:
Dave Crocker - After commenting on the value of general objectives, Dave
asked for specific short-term scenarios describing what specific items are
needed.
Unknown speaker - Discussion of whether these requirements apply to all
services, or only to regulated services (PCH does not provide E911
connectivity.) Bill Woodcock responded that there is no consumer requirement
to provide E911 services. He doesn't believe there's a legal requirement
placed upon users of peer-to-peer devices that they magically make them do
anything special when someone dials "911". 
Dave Oran paraphrased Hal's request as asking for authorized emergency users
to be authorized to perform DoS attacks on other users. 
Scott Bradner rephrased the preferential treatment request as a request for
definable probability of successful communication.
Scott Bradner suggested that SLAs are an implementation detail.
Scott Bradner and Ran Atkinson pointed out that confidentiality, integrity,
etc are end-to-end problems, not network problems.
Peter Lothberg said that the network cannot do anything about keeping up a
"connection" that it does not know about.  The network knows about packets,
not connections. 
Scott Bradner pointed out that whether or not we can meet Hal's objectives,
it is helpful to know about the objectives 
Bill Woodcock suggested that the PSTN cannot be made to meet the security
requirements proposed in this draft.
Unknown speaker suggested that TDM is subject to significant DoS, so why
does IEPrep need something special? 
Another unknown speaker emphasized the value in separating the end system
issues from the network issues since they are mixed in the draft.
Dave Crocker suggested that there may be things that may need to be done in
the network.  And we should concentrate on those things that can be done in
the near term.  Emphasis on end-point only and end-point / access solutions
may be useful in the near term. 
Unknown speaker suggested a requirement on the emergency handling of email,
and particularly with the interaction with SPAM filters.

Ken Carlberg presented "IEPrep Framework"
This is a document on IP Telephony emergency needs; some rewording will
occur and example solutions removed. 

Mike Pierce presented "Accounting" 
Accounting Requirements for Priority Services is not about packet level
accounting.
However, he did not restrict this to just SIP.  
There was discussion of the meaning of "requirement".
Particularly interested in auditing, verifying conformance to usage policy
ARCH slide actually is referencing RFC 3334.

Questions/Comments from the audience.
Henning Schulzrinne asked whether this is a SIP call accounting issue.
There is ongoing work in SIPPING on accounting related issues. 
Peter Lothberg chimed in on the unreasonableness of packet level accounting.

Scott Bradner suggested looking at the SIPPING and AAA work to see if that
meets the needs. 

Scott Bradner wrapped up. WG chairs and ADs will get together to discuss
next steps. Henning Schulzrinne's document is almost ready to ship to
SIPPING.
 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 22 Nov 2002 21:35:21 -0500

On Friday, Nov 22, 2002, at 20:01 America/Montreal, King, Kimberly S. 
> service to what remained connected.

s/they/@Home/
s/capacity/backbone capacity/

:-)