Subject: [Speermint] Comments on draft-ietf-speermint-terminology

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 18:32:38 -0400

I did a review of the most recent terminology draft. I haven't been 
actively involved in discussions so I apologize if any of this has been 
discussed or covered.

> This document introduces standard terminology for use in
>    characterizing real-time session interconnection.  Note however, that
>    while this document is primarily targeted at the VoIP interconnect
>    case, the terminology described here is applicable to those cases in
>    which service providers interconnect using SIP signaling for real-
>    time or quasi-real-time communications.

This last sentence seems odd, since VOIP interconnect *is* real-time 
communications. I think you mean "...using SIP signaling for non-voice 
or quasi-real-time communications."

> The remainder of this document is organized as follows: Section 2
>    provides the general context for the SPEERMINT Working Group.
>    Section 3 provides the general definitions for real-time SIP based
>    communication, with initial focus on the VoIP interconnect case, and
>    Section 5 briefly touches on terms from the ENUM Working Group.
>    Finally, Section 6 introduces the concept of federations.

what happened to section 4?

>  Figure 1 depicts the general session interconnect context.  In the

I think the vertical axis is meant to show layering of identifiers, 
though this is never called out. In that regards, its a bit misleading 
since it makes it seem like speermint is specifying a lookup service, 
which is not really true.

The text also jumps in and starts right away with e164 discussions. Its 
probably a good idea to point out up front that speermint is not coupled 
to e164 numbers.

> The ENUM Working Group is primarily concerned with the acquisition of
>    Call Addressing Data, or CAD, 

You haven't defined this yet. Its worth doing so here.

> More specifically, the CAD is the set of parameters that the outgoing
>    border elements need to complete the call, and may include:

This is the first time you've used the term border element.

>  o  Congestion Control parameters, including
> 
>       *  Static settings
> 
>       *  Dynamic protocol to use, if any

its not clear to me at all what is implied by congestion control 
parameters. Is this TCP window sizes? DSCP codepoints? Maybe some examples.

>  For purposes of this document and the SPEERMINT and ENUM Working
>    Groups, a peer network is defined to be the set of SIP servers and
>    end-users (customers) that are controlled by a single administrative
>    domain and can be reached via some IP path.  That is, SPEERMINT peer
>    networks are not interconnected only via the PSTN.

This last sentence would seem to imply that a peer network has at least 
PSTN connectivity, which is not a requirement for a peer network.

> 3.5.  Service Provider
> 
>    A Service Provider (or SP) is defined to be an entity that controls a
>    "network" as defined in Section 3.4, and provides transport of SIP
>    signaling and media packets.

Section 3.4 defines the term 'peer network', not network.

Also, the term 'transport' is vague here. Its not clear from this 
definition as to whether a service provider has to have an IP network or 
not. I.e., based on this definition, would Vonage be a service provider?

> A Voice Service Provider (or VSP) is an entity that provides
>    transport of SIP signaling (and possibly media streams) to its
>    customers.  

This definition of voice service provider is nearly identical to 
'service provider'. Here is the definition of SP:

  A Service Provider (or SP) is defined to be an entity that controls a
    "network" as defined in Section 3.4, and provides transport of SIP
    signaling and media packets.

The difference being that VSP has media streams as optional, and an SP 
owns a 'network', while a VSP doesn't. However, the definition of a peer 
network is:

the set of SIP servers and
    end-users (customers) that are controlled by a single administrative
    domain and can be reached via some IP path.

Transporting SIP signaling and media packets would seem to imply having 
a set of SIP servers, so I'm confused.

> Note that as soon as a ingress point is advertised via a SRV record,
>    anyone can find that ingress point and hence can route calls there
>    (although this does not mean the call will be accepted).  This is
>    very similar to sending mail to a Simple Mail Transfer Protocol (SMTP
>    [RFC0821]) server based on the existence of a mail exchange (MX)
>    record.

This paragraph appears in the middle of the definition of VSP and seems 
out of place.

> Layer 5 (Session) peering refers to interconnection of two service
>    providers for the purposes of routing real-time (or quasi-real time)
>    secure call signaling between their respective customers using SIP
>    methods. 

Seems odd that security is a required part of layer 5 interconnect. So 
if two providers interconnect without sip over tls or ipsec or whatever, 
is that NOT layer 5 interconnection?

> Section 4.3 and Section 4.4 below).  Note that media streams
>    associated with this signaling (if any) are not constrained to follow
>    the same set of paths.

You haven't defined 'paths'. Since this could be a sequence of SIP 
servers, a sequence of ASs, a sequence of VSP, a sequence of SP, a 
sequence of IP router hops, I think you need to define it.

> 4.5.  Assisted Peering
> 
>    In this case a federation employs a central SIP proxy (which is not
>    itself a VSP) to bridge calls between participating networks.

You have not defined federation in the context of speermint. Its also 
unclear to me how this is not the same as indirect peering.

> 5.  ENUM
> 
>    ENUM [RFC3761] defines how the Domain Name System (DNS) can be used
>    for identifying available services connected to one E.164 number.
> 
> 5.1.  Carrier of Record

Maybe this is a can of worms, but....

the previous sections declare ENUM as out of scope for speermint. Yet 
here is a whole section defining enum terminology.

> Finally, note that ENUM is not constrained to carry only data (CAD)
>    as defined by SPEERMINT.  In particular, an important class of CAD,
>    the tel URIs [RFC3966], may be carried in ENUM.

The definition of CAD in the document says it has a SIP URI. So how can 
a tel URI be a class of CAD?

> The domain policy DDDS application [I-D.lendl-domain-policy-ddds]
>    defines a method with which a domain owner can announce the policy it
>    will use to accept incoming calls.  This section introduces a policy
>    type for use with that framework, known as federations
>    [I-D.lendl-speermint-federations].  Importantly,
>    [I-D.lendl-speermint-federations] does not define federation rules or
>    how they are communicated to the members of a federation, and does
>    not require such rules be publicly visible.

Seems odd to me to start the definition of federation with a description 
of the mechanism for learning policies to talk to one. I'd suggest 
striking this paragraph.

> 6.1.  Federation Functionality
> 
>    A federation may provide some or all of the following functionality:
> 
>       *  Common policies

Some examples of what a 'common policy' is, would be helpful. There are 
some policy examples later in the document, but you define several types 
of policies:

       * Federation security policies

       *  Interconnection policies

       *  Other layer 2 and layer 3 policies

what are all of these?

> 6.2.  Announcement of Federation Membership
> 
>    Announcement of federation membership is typically made by the
>    terminating SP, using one or more of the following mechanisms:

An enumeration of federation announcement mechanisms seems out of place 
for a terminology document.

> 0.  References
> 
> 10.1.  Normative References

I personally find it odd to use normative references from a terminology 
document, but YMMV.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: David Meyer <[email-masked]>
Date: Tue, 12 Sep 2006 15:56:46 -0700

Thanks Jonathan. I'll incoprorate your comments in the next
version. --dmm

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 14 Sep 2006 00:40:39 +0200

> parameters. Is this TCP window sizes? DSCP codepoints? Maybe some examples.

I proposed these points primarily to indicate where congestion control
data (which a number of people seem to want) appears in the picture. 

These points refers to the SIP layer. Lower layer parameters (DSCP,
or other QoS settings) fit right in the Call Routing Data as well.

Without going back to the list archive (the WLAN here at VON is terrible), 
I remember the following points:

   * Limits on total number of calls to that peer.
   * Limits on INVITEs/second
   * Limits on total bandwidth used on a peering link

>From my point of view, all this is completely optional.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 14 Sep 2006 00:40:39 +0200

/ol

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Sep 2006 15:47:33 -0400

I think it would help enormously to include these examples and make it 
clear that this is referring to the SIP layer.

-Jonathan R.

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Sep 2006 15:24:10 -0700

> clear that this is referring to the SIP layer.

	Done :-) I'll have -05 out tonight or tomorrow AM.

	Thanks for the great feedback all.

	--dmm

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Sep 2006 18:48:50 -0400

As long as the term used is "congestion control", this is going to be 
confusing. In addition to Jonathan's suggestions, might I suggest, perhaps, 
"overload control", or something similar?

Thanks!

Spencer

>> Without going back to the list archive (the WLAN here at VON is 
>> terrible), I remember the following points:
>>

---

From: "Geoff Devine" <[email-masked]>
Date: Fri, 15 Sep 2006 08:06:50 -0400

I think congestion control is the appropriate term.  It means you have exhausted some resource.  It could be CPU.  It could be media gateway ports.  It could be IP network capacity.

Geoff

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thu 9/14/2006 6:48 PM
To: [email-masked]
Subject: Re: [Speermint] Comments on draft-ietf-speermint-terminology

Thanks!

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Sep 2006 08:51:37 -0500

Hi, Geoff,

Yes, except that "congestion control" has been used for twenty years in the 
IETF to describe resource exhaustion at the IP layer, and reusing it to 
describe something else will continue to confuse anyone in the IETF who 
knows what TCP is.

Jonathan's note, which I was referring to, specifically said "and make it 
clear that this is referring to the SIP layer". That was also my 
understanding. You're saying "congestion control" could mean something else. 
This does not look like a promising start for clear communication.

If "flow regulation" is a better choice than "overload control", that's 
fine, too.

Spencer

----- Original Message ----- 
From: "Geoff Devine" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Friday, September 15, 2006 7:06 AM
Subject: RE: [Speermint] Comments on draft-ietf-speermint-terminology

I think congestion control is the appropriate term.  It means you have 
exhausted some resource.  It could be CPU.  It could be media gateway ports. 
It could be IP network capacity.

Geoff

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]]
Sent: Thu 9/14/2006 6:48 PM
To: [email-masked]
Subject: Re: [Speermint] Comments on draft-ietf-speermint-terminology

Spencer

---

From: Scott W Brim <[email-masked]>
Date: Fri, 15 Sep 2006 10:01:45 -0400

Congestion control doesn't mean you have exhausted a resource, but
rather that you are attempting to avoid doing so.  I believe it could
apply to all of the techniques listed.  If it's a problem, how about a
more inclusive term, e.g. "resource control"?

swb

On 09/15/2006 09:51 AM, Spencer Dawkins allegedly wrote:
> Hi, Geoff,
> 
> Yes, except that "congestion control" has been used for twenty years in
> the IETF to describe resource exhaustion at the IP layer, and reusing it
> to describe something else will continue to confuse anyone in the IETF
> who knows what TCP is.
> 
> Jonathan's note, which I was referring to, specifically said "and make
> it clear that this is referring to the SIP layer". That was also my
> understanding. You're saying "congestion control" could mean something
> else. This does not look like a promising start for clear communication.
> 
> ----- Original Message ----- From: "Geoff Devine"
> <[email-masked]>
> exhausted some resource.  It could be CPU.  It could be media gateway
> ports. It could be IP network capacity.
> 
> Geoff
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Sep 2006 09:08:31 -0500

Hi, Scott,

OK, I finished my diet Pepsi. Yes, I meant "*attempting to avoid* exhausting 
a resource". Thanks for reading my mind.

"Resource control" would be an improvement, but doesn't mean "the SIP 
layer", as Jonathan said in his note.

Thoughts?

Spencer

---

From: David Meyer <[email-masked]>
Date: Fri, 15 Sep 2006 07:35:32 -0700

On Fri, Sep 15, 2006 at 09:08:31AM -0500, Spencer Dawkins wrote:
> Hi, Scott,
> 
> OK, I finished my diet Pepsi. Yes, I meant "*attempting to avoid* 
> exhausting a resource". Thanks for reading my mind.
> 

	Current text:

   o  Optional congestion control parameters such as

      *  Limits on the total number of calls to a peer

      *  Limits on the total amount of bandwidth used on a peering link

      *  In addition, lower layer parameters (such as DSCP) might also
         be included.

	IMO its pretty clear what is trying to be communicated
	here. i.e., that there are various parameters associated
	with the control of resources in both the L3 and L5
	peering(s) that might be communicated in the CAD.

	That being said, if folks like "resource control" better,
	I don't have a strong objection to that.

	--dmm

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 11:07:50 -0400

Dave,

This looks good. I would suggest further clarifying that DSCP markings 
are referring to markings on the SIP packets. As you know, there is a 
whole other interesting question on using the SIP signaling to drive 
DSCP marking on the RTP packets across a boundary.

-Jonathan R.

David Meyer wrote:

> ------------------------------------------------------------------------
>

---

From: David Meyer <[email-masked]>
Date: Fri, 15 Sep 2006 08:13:26 -0700

> DSCP marking on the RTP packets across a boundary.

	Yep. And will make that clarification. Thnx, --dmm
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Daryl Malas <[email-masked]>
Date: Fri, 15 Sep 2006 09:15:59 -0600

Dave,

I think the current text is pretty straight-forward.  We could spend a
lot of time trying to apply creative terms regarding all of the various
aspects surrounding possible L3 and L5 contention points and how to
avoid them, but then we would have a whole other draft and still not be
complete as new variables are presented with different protocols,
hardware, and in different topologies.

IMO, this works fine.

Thanks..--Daryl

---

From: David Meyer <[email-masked]>
Date: Fri, 15 Sep 2006 09:16:25 -0700

> hardware, and in different topologies.

	Agreed, and thnx.

	--dmm

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 15 Sep 2006 12:51:24 -0400

Hello,

I'm not sure this should be restricted only to SIP Packets. Media
packets (RTP, and others) should be included as well. Whether they use
the methods proposed by some other WG or something else that's another
issue. What we are trying to capture is simply that there is a
requirement to inform/suggest DSCP markings across the pering point.

Also, handling of media (although not prime time until now), is in the
charter.

Regards,

Reinaldo

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 8:08 AM
> To: David Meyer
> Cc: [email-masked]
> This looks good. I would suggest further clarifying that DSCP 
> markings are referring to markings on the SIP packets. As you 
> know, there is a whole other interesting question on using 
> the SIP signaling to drive DSCP marking on the RTP packets 
> across a boundary.
> 
> -Jonathan R.
> 
> David Meyer wrote:
>

---

From: David Meyer <[email-masked]>
Date: Fri, 15 Sep 2006 10:14:01 -0700

> Also, handling of media (although not prime time until now), is in the

	Ok, current version on 

	http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-05.txt

	--dmm