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

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 7 Apr 2006 14:59:39 -0400

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: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 15:17:48 -0400

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.

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).

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

the
in
[[Reinaldo]] 

this
for
requirements
packets
to
I
origin
an
[[Reinaldo]] 

As I mentioned before:

mechanisms
SBC's
an
be
[[Reinaldo]] 

Could not agree more.

[[Reinaldo]] 

Please elaborate.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 7 Apr 2006 21:46:44 -0400

Hey Brian,
I think that would be one place to start for media.
One thing is it's different for different media types (audio, video, image,
etc.).  But it doesn't have to be per call-flow; just the "policy rule"
exchanged has to define the media-type+dscp and applied to all media flows
going to T.  

-hadriel

> Sent: Friday, April 07, 2006 3:18 PM
> To: 'Reinaldo Penno'; [email-masked]
> Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background
> ReadingonNGNInterconnect-transitvs peering
> 
> So, from this I get