Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering

From: "James McEachern" <[email-masked]>
Date: Tue, 11 Apr 2006 17:51:15 -0400

Brian,
Perhaps it is just an issue of terminology, but if an "originating" network knows how to map from its internal marking to something appropriate for each "peering destination network", and every other originating network has a similar mapping for each of its peering destination networks, then in aggregate we have a mapping for every O-T (or O-D) pair.

Jim

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 3:43 PM
> To: [email-masked]; McEachern, James [CAR:5N00:EXCH]; 'Patrick
> Melampy'; [email-masked]
> Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> Yes, well we aren't doing a good job of separating our terms, and transit
> networks are indeed a fact of life.
> 
> So, yes, I think it's the peering destination network, which would be
> "next-hop" at the peering point who would have a marking policy.
> 
> We could define this away by saying it was that network who was
> responsible
> for marking its packets any way in wants on entry, rather than the peering
> "network"'s responsibility.
> 
> I don't think we need an O-T pair; I think we need a T (or as Tim says,
> next
> hop) policy.  Every flow to that next hop gets marked the way that network
> wants it.  Source doesn't matter.
> 
> IN THE PEERING FABRIC, I think it probably doesn't matter; I think you can
> probably do admission control into the fabric that makes diffserv within
> the
> fabric unnecessary.  If you did want it, then you have to remark on
> entrance
> to the fabric with the fabric's code points, and then remark again with
> the
> next hop network's desired codepoints.
> 
> Brian
> 
> -----Original Message-----
> From: Tim Dwight [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 12:11 PM
> To: 'James McEachern'; [email-masked]; 'Patrick Melampy';
> [email-masked]
> Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> Wouldn't the marking need to be per the requirements of the adjacent
> network
> rather than the network in which the session terminates?  We are talking
> about L3 markings and there may be multiple L3 networks between O and T.
> 
> Tim
> 
> 
> -----Original Message-----
> From: James McEachern [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 11:06 AM
> To: [email-masked]; Patrick Melampy; [email-masked]
> Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs
> peering
> 
> Comments inline.
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Monday, April 10, 2006 3:45 PM
> > To: 'Patrick Melampy'; [email-masked]
> > Subject: RE: [Speermint]
> > RE:BackgroundReadingonNGNInterconnect-transitvs
> > peering
> >
> > I personally think this is way over the top for a BCP.
> >
> > If such things were deployed now, even experimentally, and we had some
> > good reports on complexity, stability and usefulness, then maybe we
> > could document that as "Best Current Practice".  In the absence of
> > anything like it, to my knowledge, in the wild, I'd say let's not go
> > there.
> >
> > I'm pretty certain that an objective evaluation of this scheme would
> > result in a "more bandwidth is cheaper" conclusion, but since my
> > speculation isn't any more valid that yours I think we just
> > fagetabodit.
> >
> > Can we just stick with per T-domain marking and DiffServ?
> 
> [JMcE] If we have per T-domain marking and DiffServ, then presumably we
> must
> have a policy that specifies the translation for each O-T pair.  If we
> agree
> on this, then does it really matter if that "per O-T translation policy"
> has
> a single entry, an entry per media type, or multiple options per media
> type?
> If fact, once we allow for such translation, do we even need to specify
> how
> many options are possible?
> 
> >
> > Brian
> >
> > -----Original Message-----
> > From: Patrick Melampy [mailto:[email-masked]]
> > Sent: Saturday, April 08, 2006 10:53 AM
> > To: [email-masked]
> > Subject: RE: [Speermint] RE:
> > BackgroundReadingonNGNInterconnect-transitvs
> > peering
> >
> >
> > Brian,
> >
> > This new kind of policy driven marking thing must work across network
> > borders -- and across trust boundaries. What we really need to solve
> > the routing problem is a second forwarding equivalence class -- one
> > for best efforts, and one for voice. These must be advertised through
> > BGP4 edges to effect a second routing plane. Only then can you solve the
> routing problem.
> >
> > If this was all completed, and we could make packets route differently
> > based on service (different next-hop networks), we have solved a first
> > problem.
> > However it is unclear that we have made the internet better. Now when
> > you "ping" an address, you get a different response if the ToS is best
> > efforts verses Voice. You also would have to revise ICMP handling to
> > deal with "unreachable address messages" to take into account the ToS.
> > There may be many other protocol issues that occur when these bits are
> not
> set properly.
> >
> > I can think of one simple one.
> >
> > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is
> > ONLY reachable in the ToS Voice forwarding plane. However, when I use
> > the Berkely Sockets to create the socket ... the syn/syn syn/ack ack
> > three way handshake doesn't have the ToS bits set yet (since I can't
> > do a SOCKOPTS until the socket is opened). Thus we would have to alter
> > the ways Berkely sockets work to ensure that the 3way TCP handshake
> > routes properly.
> >
> > These complications may be worth the salvation of honor and avoidance
> > of doing something evil like a simple NAT like SBC's do.
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Friday, April 07, 2006 3:03 PM
> > To: 'Michael Hammer (mhammer)'; [email-masked]
> > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background
> > ReadingonNGNInterconnect-transitvs peering
> >
> > Uh-huh, at least for a generic "everyone should do this" kind of thing.
> >
> > I have no illusions that big complex carrier networks will adopt
> > anything as straightforward as -service-classes, but many more focused
> > carriers could, and profit there-by.
> >
> > So, I think our BCP should reference that work, but I believe it's not
> > sufficient.  We probably need some kind of policy driven re-marking
> thingy.
> >
> > What I'm not so sure about is PER FLOW decision making.  PER "T-NETWORK"
> > is
> > maybe doable.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Friday, April 07, 2006 2:55 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background
> > Reading onNGNInterconnect-transitvs peering
> >
> > Brian,
> >
> > Are you talking something like?:
> > draft-ietf-tsvwg-diffserv-service-classes-02.txt
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Friday, April 07, 2006 1:44 PM
> > > 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.
> > >
> > > ....
> > >
> > > >>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?
> > >
> > >
> > >
> > >
> > >
> > > >>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.
> > >
> > > Then we could consider per-flow marking.  I'm not so sure I want to
> > > go there, but I'm willing to listen.
> > >
> > > 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
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> 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: Wed, 12 Apr 2006 09:48:30 -0400

Jim

Need a picture:

O ---- P ---- T
         ^

You mark at the exit of the peering fabric with the T marking (where T here
is either the terminating network or the transit network as Tim suggests).

You could mark on entrance, but then, as you suggest, you would have O-T
pairs.
O ---- P ---- T
 ^

Of course, as I pointed out, there are two sides to the exit (and entrance).
If the peering system does the marking, it's in scope. 
O ---- P ---- T
         ^ 
If the T network does its own marking on its entrance:
O ---- P ---- T
             ^
then its out of scope.

If it's done on entrance, than it's in scope.
O ---- P ---- T
      ^
Or
O ---- P ---- T
 ^

If it's done on entrance with T's marking, then the peering fabric can't use
markings (can't implement DiffServ).  As I said, this may not be a problem.
If it's done on entrance with P's marking, and again on exit with T's:
O ---- P ---- T
  ^
  P
         ^
         T

then you can use diffserv in the fabric

Brian

-----Original Message-----
From: James McEachern [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2006 5:51 PM
To: [email-masked]; [email-masked]; Patrick Melampy;
[email-masked]

Brian,
Perhaps it is just an issue of terminology, but if an "originating" network
knows how to map from its internal marking to something appropriate for each
"peering destination network", and every other originating network has a
similar mapping for each of its peering destination networks, then in
aggregate we have a mapping for every O-T (or O-D) pair.

Jim