Re: My comments to the press about RFC 2474

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard:

> Russ said to the press that he considers AT&T's belief that the RFCs
> envisioned payment for premium services implemented over DiffServ or
> MPLS to be "invalid."

This is not what I said.  I said 'misleading.'

The letter from AT&T jumbles some things together.  AT&T makes many
correct points, but in my opinion, a reader will get a distorted
impression from the parts of the letter where things get jumbled.

Adding to this situation, it is clear to me that the term "paid
prioritization" does not have the same meaning to all readers.  If you
read the AT&T letter with one definition in your head, then you get one
overall message, and if you read the letter with the other in your head,
then you get a different overall message.  I tried to make this point.

This was captured pretty clearly in the article by Eliza Krigman:
| The feud boiled down to what it means to have "paid
| prioritization," ...

As I said on Friday, I made the point that DiffServ can be used to make
sure that traffic associated with applications that require timely
delivery, like voice and video, to give preference over traffic
associated with applications without those demands, like email.

Unfortunately, it is not simple, and I said so.  I used an example in my
discussion with Declan McCullagh.  I think that Declan captured this
point in his article, except that he said 'high priority', when I
actually said 'requiring timely delivery':
| The disagreement arises from what happens if Video Site No. 1 and
| Video Site No. 2 both mark their streams as high priority. "If two
| sources of video are marking their stuff the same, then that's where
| the ugliness of this debate begins," Housley says. "The RFC doesn't
| talk about that...If they put the same tags, they'd expect the same
| service from the same provider."

Clearly, if the two video sources have purchased different amounts of
bandwidth, then the example breaks down.  However, that is not the point
in this debate.

Russ

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]