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 about highly provisioned 
networks 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  @Home 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.