[geeks] P2P Monitoring / Mitigation

[der Mouse]

>> That hardly "allows ... VoIP to go through unimpeded".  If nothing
>> else, it means VoIP traffic (most RTP packets are >100 bytes) will
>> be competing with anyone trying to do anything else that hits that
>> limit.
> Are they?  AFAIK SIP packets with header compression are about 90
> bytes long. 

SIP packets are mostly irrelevant; SIP is used for call setup stuff
only (and, yes, INVITEs are often over 100 bytes).  It's RTP that's at
issue, and I can't recall ever seeing an RTP packet under 100 bytes - I
work for a provider that, among other things, sells VoI service, and
have had plenty of occasion to tcpdump the resulting network traffic.
If you use a sufficiently-compressing codec it could probably happen,
but I think G.711 (ulaw/alaw) is common enough; that's 8000 bytes/sec,
and I've never seen a phone put less than 20ms of sound per packet - at
which rate packets are 160 bytes of payload alone.

>> It wouldn't take more than some 30 simultaneous calls to blow out a
>> 1Kpps limit (depending on how much sound the implementations put in
>> a single packet).
> Ok, how big are they?  My point was to NOT limit them, by allowing
> small packets through.

I've seen anywhere from 20 to 50 milliseconds of sound per packet,
depending on the sending implementation.  That's from 160 to 400 bytes
of payload for a non-compressing codec like ulaw.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B