Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 7 Apr 2006 22:18:38 -0400

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 12:18 PM
> To: Reinaldo Penno; [email-masked]
> Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background
> Reading onNGNInterconnect-transitvs peering
> 
> So, from this I get
> Yes, you think marking is a good idea
> No, you don't think source marking is sufficient
> Yes, you think re-marking at the edge of peering is needed
> 
> Is it sufficient, at least for now, if we say we can do per-T-domain
> remarking?  That implies all media flows to a given T-domain are
marked
> the
> same way.  I can handle this.
> 
> Is this sufficient?  Do we need more than marking per T-domain?
> What I don't want to do, if we can help it, is to have to specify
> mechanisms
> where a peering domain has to use some kind of bookkeeping on flows to
> determine marking.  If all we have is a per-T-domain mark, I can deal
with
> that.
> 
> I'm saying "per-T-domain" but of course the flows from T to O are
marked
> with O's choice of mark.
[[Reinaldo]] 

Hello Brian,

I could agree with you, the issue is if the (VoIP)service
providers/carriers will think it is enough. What we are basically saying
is that _all_ media flows to/from a certain domain will be marked with
the _same_ dscp.

So, if the service provider expects some differentiation based on the
fact that a customer is a medium vs. large enterprise vs. home user, he
will not be able to do that. Since providers today use sometimes between
4 and 8 service classes (and sometimes special ones per VPN), I wonder
if our proposal will fly. Maybe the carriers/ISPs on the list could
chime in the discussion.

Now, if somebody says that the edge proxy or router has the ability to
remark everything than the whole discussion is moot. But we are assuming
media identification is done only by the endpoints because of the
bookkeeping issue you mentioned.

So, what options do we have? It seems:

1) _one_ dscp for all media flows (read all source-destination pairs)
between domain A and B. Seems limited.

2) The "edge system" in the other domain can reclassify everything (with
SIP over TLS and other things I think that would be difficult). 

3) Per flow diffserv marking. Lots of bookkeeping

4) Something in between. Maybe per destination IP address (network,
range, whatever).

5) <Put here your proposal> 

> 
> Is marking sufficient?  Does that mean DiffServ is sufficient?
> 
> Think a little about how this is done.  If the peering point has
infinite
> bandwidth, than you can mark on entry to peering, traverse the peering
> fabric, and get to the other side ready-marked.  If it doesn't, you
may
> have
> to mark on entry to the fabric using a peering-specified mark, let the
> fabric do DiffServ on a PHB it defines, then remark again on entry to
the
> other domain.  We have to say how this works, because it does affect
the
> interface to the peering point (assuming that it is the source who is
> responsible for at least the initial re-marking).
[[Reinaldo]] 

Agree, I'm only concerned about the granularity offered. 

> 
> Brian
> 
> 
> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 3:00 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background
> Reading
> onNGNInterconnect-transitvs peering
> 
> I think I must have missed a message...you are quoting/replying to
> somebody saying many things in a message I did not see...
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Friday, April 07, 2006 10:44 AM
> > To: [email-masked]
> > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background
> > Reading onNGNInterconnect-transitvs peering
> >
> >
> > I changed the subject line, at least this part of the thread may be
> > fruitful>
> >
> >
> > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or
any
> > other
> > >>kind of links down in the router.
> > >
> > >The process of getting signaled RTP data onto these tunnels, and
not
> the
> > >best efforts packets from the same IP address pairs, is essential
and
> in
> > >scope.
> >
> [[Reinaldo]]
> 
> I seem to agree with this. Who said this?
> 
> >
> > >>This doesn't say you can't mark media packets in some way that
sends
> > them
> > >>down some specific tunnels.
> >
> > >The process of doing this -- routing by packet markings -- and how
> this
> > >will
> > >be setup on a call-by-call basis from the same IP address pairs
used
> for
> > >best efforts should be in scope.
> >
> > Now we may be getting somewhere.  This seems like it creates
> requirements
> > I
> > might be able to deal with.
> >
> > What I'm hearing is that you think, fundamentally, that signaling
> packets
> > must be able to be marked differently from media packets.  Seems
hard
> to
> > argue with that.
> >
> > But I believe you want a requirement that we cover PER FLOW marking.
> I
> > think that might be something worth discussing.
> >
> > There are two ways we know how to do this.  The right way (get the
> origin
> > to
> > mark them right in the first place) and the expeditious way (put an
> > intermediary in the path and remark them).  That intermediary could
be
> an
> > L5/L7 entity, or it could be down in router-land using normal flow
> > identifier techniques.
> >
> > Are you looking for requirements like that?
> [[Reinaldo]]
> 
> Well, yes. Can domain A trust B to the point that it will trust B's
> users to mark packets correctly? And carry those marking into its
> network across the peering point? Seems like a stretch...It seems ISPs
> sometimes do not trust their own users and remark packets and the
edge.
> 
> The problem is not really mark the packets by an intermediary, but
mark
> them in an away acceptable (and maps to the correct PHB) in the other
> domain.
> 
> As I mentioned before:
> 
> If Layer 5 peering is dynamic such as some advocate, how domain A is
> going to let domain B know which flows are media and as such should
> receive better treatment.
> 
> I have more similar questions. How to reconcile PHBs used in domain A
> and B? Or even diffserv markings? Are we going to do that through the
> peering policies?
> 
> Alternatively could domain B trust domain A to remark media packets at
> the border with the dscp that make sense in domain B. Or will domain B
> do it?
> 
> Or is each domain responsible for looking into the SDP information and
> marking/scheduling independently. This is certainly simpler (although
> the results are questionable), but seems to defeat somewhat the
purpose
> of peering, which implies some cooperation.
> 
> >
> >
> >
> >
> >
> > >>This doesn't say you can't create any kind of static routing
> mechanisms
> > you
> > >>like for any set of flows you can identify.
> >
> > >Once again....how to use these static routes (which is often why
> SBC's
> > are
> > >used--essentially creating the head of a static route) needs to be
> > studied
> > >by this group.
> > Well, is this any different from the marking issue above?  What do
you
> > want
> > the BCP to say beyond marking of packets?  What is the requirement?
> >
> > Marking of packets is a subject worthy of discussion I think.
> >
> > In the best of all worlds, we would agree on the proper marking of
> > packets,
> > all networks would mark in a uniform way, and routers would route in
> an
> > optimal manner for the packets marked appropriately no matter how
many
> > domains the packets crossed.
> >
> > Dream on you say.
> >
> > I agree, but we should, probably, at least mention the ideal (which
> > implies
> > we actually specify what the marking should be).  I'd expect to see
> > signaling packets marked differently than media packets.  There
could
> > reasonably be different marking for different kinds of media (text
vs
> > audio
> > vs video, for example).
> >
> > Then we have to deal with the reality that marking within a domain
may
> be
> > consistent, but in peering, the O marking won't be the same as the T
> > marking, and we need to remark at the peering edge.
> [[Reinaldo]]
> 
> Could not agree more.
> 
> >
> > Then we could consider per-flow marking.  I'm not so sure I want to
go
> > there, but I'm willing to listen.
> [[Reinaldo]]
> 
> Well, is there any other way? Are we assuming gazillions of call-pairs
> across a peering point will have the same markings??
> 
> Please elaborate.
> 
> 
> >
> > But is there more than that?  What, exactly?
> >
> > Brian
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 7 Apr 2006 22:40:25 -0400

I think if different service classes are used for enterprise vs. consumer,
then you're inferring the T-partner also has an agreement to service such
classes, else it wouldn't want O-partner to differentiate such to it.  So if
you do have such an agreement, wouldn't it just be done with two logical
T-partners?  At least that's what I was thinking when he said it, but I
haven't thought it through.

-hadriel

> Sent: Friday, April 07, 2006 10:19 PM
> Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background
> ReadingonNGNInterconnect-transitvs peering
> 
> 
>