A few years ago, Comcast generated a lot of negative PR based on their RST–injecting P2P throttling scheme.
This lead them to adopt a new strategy which is protocol and destination-agnostic and is designed to shift inevitable packet-loss to those users that stress the network.
Comcast has now published their strategy in an informational RFC. It’s longer than it needs to be, but still: recommended reading.
On 09.03.2010 18:27, Dean Willis wrote on the IETF dispatch list:
I definitely see the need for defining a method by which to inform nodes inside an ITAD of egress routes from that ITAD to other domains. I think that most of the people who have responded on this thread agree that there is such a need.
Yes, there is.
Where we have a disagreement is on mechanism. While your proposed use of ITAD-specific private ENUM servers is not completely inconsistent with recent trends in ENUM, I have to say we’ve done a lot of things in ENUM that I don’t like, and this is pushing the envelope further in that direction.
As I see the problem space, we’re conflating two independent problems:
a) how is routing-information exchanged between SSPs?
Here we have one approach which favors registries which digest routing-information and spit out suitable database dumps for provisioning the SSPs boxes. The other approach is to get some real routing-protocol up and running between SSPs (like BGP4 for IP layer 3 routing).
b) how is this routing-information conferred to the proxies/SBCs/… which do the actual SIP message processing / forwarding?
Now, if these proxies are actually participating in a dynamic routing protocol (or receive full dumps from a routing registry), then b) is internal to the proxy. Just as there is no protocol for moving routes from the BGP table of a router to the actual packet forwarding engine, this is purely internal to the box.
If, on the other hand, some entity distinct from the actual SIP devices handles the routing information (either by talking to a registry, or by running a dynamic routing protocol), then the SIP device needs a protocol to query that routing-oracle on what to do with a given call.
It seems to me that this is what ENUM is increasingly used for within SSPs.
IMHO this is the wrong protocol choice for this task.
Why?
* ENUM is a very simple DNS application. The only key to the lookup is the destination number, the only return value is an URL. (more or less)
* If you look at a good number of recent drafts you notice that people feel that this is not enough: they need “ID of the SIP device” or “caller-ID” in the query, and a sh*tload of URI-parameters (trunk-id, …) in the answer. See draft-mayrhofer-drinks-sed-elements for further data that might need to get stuffed into an ENUM response.
ENUM was never intended as call-control protocol where a proxy outsources its complete routing intelligence to an external party. It’s a simple key->URI directory lookup. The LRF (RFC 3263) and the intelligence was supposed to be within the SIP proxy.
Now, what we need here is something closer to RADIUS than to ENUM: a protocol where the SIP device can pack up all the information it has about the SIP INVITE into one request to the routing-oracle which then answers with a details set of parameters (the SED) on what the stupid proxy is
supposed to do now.
Trying to expand ENUM into doing just that is bound to fail.
The IETF Meeting started today in Hiroshima (without me), the speermint session is tomorrow at an ungodly hour with respect to CET, but the real news is somewhere else:
JD Rosenberg left Cisco and joins Skype.
and
Jonathan and Cullen published a new VoIP interconnection idea.
Their analysis is similar to mine, but their solution starts with a different set of requirements.
Their main idea is not to build something which is capable of obsoleting the PSTN, but build something which leverages the strength of the PSTN to enable direct SIP peerings.
Definitely worth a read. This could be huge, especially as JD writes:
This technology is not just documents – it is working code, and was announced by Cisco today as part of their products shipping early next year.
If he manages to get that idea into Skype as well and if the IPR allows Open Source implementation, then ViPR-enabled PBXs will make an end-run around the carriers.
We live in interesting times.
UPDATE: See also this.
Ken recently expressed doubts about the direction drinks is taking.
During a train ride last week I composed the following reply:
In the wake of .org going signed, we finally have good data what that means for the authoritative nameservers. Duane gave a good talk at the recent NANOG event, showing the increase of TCP connections.
So what is the problem?
In a nutshell: Packet sizes. DNS responses containing the DNSSEC specific RRSETs are larger, and setting the DO bit that triggers their inclusion is almost default these days. So we’re now routinely exceeding the 512 bytes that the original DNS spec required. Over the years, the IETF defined EDNS0 which allowed clients to announce their support for larger responses via UDP. Not this is finally really put to the test and we can see how fallback to TCP we still observe.
One of the three authors has retired.
One has left the company.
One has a new assignment within the same company.
Three years after the “Dallas treaty“, when most of us have stopped believing that this will ever happen, we’re now finally in AUTH48: Combined User and Infrastructure ENUM in the e164.arpa Tree
[UPDATE, 2009/05/05]
Today I gave a talk at the ISPA office concerning DNSSEC. See here for the official announcement.
Attendance was good, we had interesting questions and a lively discussion.
You can download my slides in pdf format.
I’ve written about this already a few times in various IETF / RIPE lists, but it seems to be relevant to the current draft as well, so here is a repeat:
According to the usecases draft, SSPs report the public identities of their customers to the registry so that the registry can store the mapping to destination groups. All fine and dandy for TN based public identities, but what about sip:user@domain?
These URIs come in (at least) two flavors:
a) the domain is the provider’s domain (e.g. “verizon.com”)
b) the domain is owned by the customer (e.g. “shockey.us”)
The first one makes it easy for the SSP to authoritatively tell the registry that it provides service for whatever URI it is going to provision. So from the point of drinks, this is easy.
[I still very much doubt that solely offering such PIs to customer is dangerous to the SSPs as they might be forced to offer PI portability, which would really mess up a lot of assumptions.]
So what about b)? Portability is a given, and ISPs are used to deal with customer-owned domains for email and web. Good. So what’s the authorization mechanism? For email and the web it’s simple: the entity which controls the domain must set the respective MX and CNAME/A records so that the rest of the world know who provides email/web services for this domain. If the control over the domain changes, so does instantly change the control over email and the website.
Now, if a SSP can provision any URI regardless of the domain ownership status / domain content, this opens up a pandora’s box of interesting errors. We now duplicate who operates SIP service for a domain in two databases which can and will run out of sync with each other.
I consider it thus a lot more in line with the rest of the Internet protocols to store the mapping domain -> destination group in the DNS and not some other registry.
Richard wants feedback, so here it comes.
This document is a _lot_ better than -01. Much more consistent.
Overall impressions:
All fine and good, but to be provocative: why is this an IETF WG document and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a most use-cases are almost straight from the PSTN playbook.
Layering, folks. Layering.
Divide the problem into discrete, clearly separated sub-problems (see the speermint LUF/LRF split for a good one) and the complexity can be brought under control.
Okay, some specifics:
This time I manged to publish a new version of my speermint thesis-like I-D in time. Phew. Spending time in trains is sometimes the best way for me to focus on a single subject. That used to be easier; now with 3G on the phone I can connect to the Internet while riding trains which provides ample fodder for distractions. Anyway, …
This update isn’t so much an update on the existing text, but instead adds a few new sections. Whereas the old text just analyzes the problem-space and lays out some generic principles, the additional text now provides a vision on what the solution could look like. As a bonus, I also discuss a few design mistakes I saw in various other documents.
Feedback is welcome.
[Update: My slides for the IETF session are here. Thanks to Alex for standing in for me. This pdf contains the comments I added to help Alex. ]