Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Mon, 2 Dec 2002 12:54:38 EST

In a message dated 12/2/2002 11:18:10 AM Eastern Standard Time, 
[email-masked] writes:

> On Monday, Dec 2, 2002, at 10:30 America/Montreal, [email-masked] 
> wrote:
> > [MAP] So take this simple case and apply an emergency. (I'd like to 
> > see the performance last week right after the bombing in Kenya!)
> >
> > If 10 or 20 or whatever number of those "several thousands" of end 
> > users tried to make a VoIP call via that single 384K link, what would 
> > have happened? It is my understanding that, at some point, the 
> > overload would have caused either:
> >
> > 1. all calls to be of unacceptable quality
> > 2. new call attempts would have been rejected
> 
>   [RJA]  The IP-layer doesn't have the concept of a "call", so (B) can't 
> happen at
> the IP-layer.  Bill's SIP server is not on the access link (as I understand 
> it),
> so would not be subject to the emergency -- it would be able to process 
> calls
> normally without any MLPP.  (Bill please clarify these points.)
> 

[MAP] I understand fully that the IP-layer is unaware of "calls" or "voice 
packets". That wasn't the point. If some higher layer function doesn't limit 
the setup of new calls (2. above) when it knows that there are already too 
many being stuffed through a finite size link, then the IP-layer would be 
overwhelmed with packets which it can't handle (1. above).

> [RJA]    If congestion on the last mile link occurred (which we don't know 
> right now),
> then it could ONLY be solved using link-specific deployed mechanisms (e.g. 
> router
> CoS like Sprint/Genuity described would be sufficient).  If congestion 
> occurred,
> then what would have happened is probably packet loss (after the packet 
> buffers
> on the access routers filled up).  How much packet loss occurred depends on 
> the
> depth of those buffers, the offered load, the link capacity, etc.  So we 
> don't
> know whether congestion occurred (yet, Bill should ask) or exactly what 
> happened if it occurred.
> 

[MAP] So I take that as an agreement with what I said, that in the case of 
congestion, a lot of packets would be lost. However, you still seem to 
question whether or not congestion can occur. Please explain: If 10 users 
each try to make a phone call (each of which I understand needs 80+ kbit/s) 
and they all have to go across the same 384 kbit/s link through a satallite, 
how can you argue that congestion does not occur? (Change the numbers if you 
want, but a case such as this can always exist.)
> 
> [RJA] Concrete existing solutions:
>     1)    Deploy link-specific QoS.  For DSL see T1/ANSI/ITU-T standards,
>         for Ethernet see 802.1p, for cable modems see DOCSIS standards.
>     2)     Deploy access router CoS (a la Sprint/Genuity product offerings).
>          This is already widely available and is outside of IETF's scope 
> since
>          it is an implementation detail inside of a router.
> 
> Please STOP claiming that concrete solutions to the access link congestion
> issue have not been offered.  It is a bold-faced lie and it is quite 
> tiresome
> at this point.
> 
> And please STOP claiming that IETF lacks mechanisms that DoD could use to
> deploy MLPP internally.  DiffServ is on the standards track already with
> AF and EF.  So that is another bold-faced lie.
> 
> It is just not productive when you keep repeating claims that are obviously 
> untrue
> to anyone reading the list's archives.
> 

[MAP] I'll repeat the question which I don't believe I've gotten any concrete 
answer to: In the case above of the 10 callers from Nairobi, if one of them 
was authorized to make emergency calls and the other 9 weren't, what specific 
standardized mechanism (not products) could be used to provide the required 
service across the congested 384 kbit/s satellite link? (The required service 
is that their call gets set up and they can talk.) If you don't believe that 
10 users would cause congestion, then make it 20 or however many of the 
several thousand it would take.

I would find it hard to believe that there are no standardized solutions to 
this. You're right, maybe there is no need for this WG, but I haven't heard 
the solution yet.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 15:23:50 -0500

On Monday, Dec 2, 2002, at 12:54 America/Montreal, [email-masked] 
wrote:
> [MAP] I understand fully that the IP-layer is unaware of "calls" or 
> "voice packets". That wasn't the point. If some higher layer function 
> doesn't limit the setup of new calls (2. above) when it knows that 
> there are already too many being stuffed through a finite size link, 
> then the IP-layer would be overwhelmed with packets which it can't 
> handle (1. above).

The IP-layer can be overwhelmed anyway since IP does not have any 
equivalent
to "call setup".  Even if SIP were informed (which it isn't) and had 
some way
to control the voice calls (which it doesn't since anyone on the 
Internet can
use any cooperating SIP server, not just the local one), other 
unrelated applications
like mail or ftp or http don't use SIP (and won't be using it in 
future).

Now one could use IP ToS bits to mark the packets from inside a domain 
for
the uplink router to prioritise, if the uplink router happened to have 
that
policy configured in it by the router's operator.  One could also put 
various
other policies into the router based on some combinations of (address, 
protocol, port),
if one did not want to use the IP ToS bits.  If the link is Ethernet, 
one could
use 802.1p.  If the link is something else, then one could use other 
link-specific
mechanisms (e.g. ATM has PSTN-like calls).

> [MAP] So I take that as an agreement with what I said, that in the 
> case of congestion, a lot of packets would be lost.

No.  The number of packets lost would vary with (offered load, link 
capacity,
traffic pattern, packet memory depth on each side of the link).  In 
many cases
there is minimal or no congestion, because the router buffer is deep 
enough
to handle a trans-oceanic RTT, which in turn gives TCP or SCTP enough 
time
to reduce the transmission rate on existing sessions, which then leaves
enough room for the new traffic to be carried on the link.

> [MAP] I'll repeat the question which I don't believe I've gotten any 
> concrete answer to: In the case above of the 10 callers from Nairobi, 
> if one of them was authorized to make emergency calls and the other 9 
> weren't, what specific standardized mechanism (not products) could be 
> used to provide the required service across the congested 384 kbit/s 
> satellite link? (The required service is that their call gets set up 
> and they can talk.) If you don't believe that 10 users would cause 
> congestion, then make it 20 or however many of the several thousand it 
> would take.
>
> I would find it hard to believe that there are no standardized 
> solutions to this. You're right, maybe there is no need for this WG, 
> but I haven't heard the solution yet.

One could use IP ToS bits, link-specific ToS bits (802.1p in the case 
of Ethernet),
or some combination of (address/protocol/port) to tell the access 
router which
traffic to prefer from the site connected to that access router.  
Preference can be
implemented using the CoS mechanism that Sprint is using, various 
flavours of which
are available from many vendors.  Whether that policy (either to obey 
ToS bits or to sort
based on the address/protocol/port) is configured into that router is a 
question
for whoever  owns/operates that access router.

If the offered load of preferred traffic exceeds link capacity, then 
packets
still will be dropped.

Just don't be expecting ISPs to deploy any of this stuff inside their 
backbones,
because that would create a huge DDOS vulnerability for them (thus 
reducing the
probability of "call" completion well below what is the case today).  
It is both
cheaper and more effective to overprovision backbones.

Ran

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