Subject: RE: [Tsvwg] Re: [NSIS] interoperability problems between end-to-endECNandedge-to-edge ECN

From: [email-masked]
Date: Thu, 17 Nov 2005 10:22:49 -0000

But then the first point - you have no idea what a network will do with
packets that from a network perspective are trying to cheat on its
reservation by sending too much data. You have no idea which packets of
your stream the network will drop as "out of spec".  As an operator I
suspect we would drop such packets even if there was an totally
uncongested best effort buffer. Re-ordering will certainly also occur.

If your probability of survival increases with bandwidth, you would
reserve more

 more bandwidth does not equal more quality

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent: 17 November 2005 10:15
> To: Burness,AL,Louise,CXR9 R
> Cc: [email-masked]; Eardley,PL,Philip,CXR9 R; 
> [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems 
> between end-to-endECNandedge-to-edge ECN
> 
> 
> louise.burness,
> 
> On Thu, 17 Nov 2005, [email-masked] wrote:
> 
> > Further, users value stability more than anything else, expts have 
> > shown that users would rather the video run at the lowest (mininum) 
> > bandwidth than fluxuate up and then down - ie lower stable network 
> > quality gives a higher user experianced quality than average higher 
> > quality
> 
> I wonder how many in the population this sample group is 
> disenfranchising. ;)
> 
> Best effort over a reserved minimum sounds like a reasonable 
> and valuable bandwidth allocation policy.  Users whose 
> probability of survival, or mission success, increases with 
> quality might have a different perspective on the matter than 
> your home users above.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> [email-masked]    | world; the unreasonable one persists in  |
> http://www.openss7.org/ | trying  to adapt the  world  to himself. |
>                         | Therefore  all  progress  depends on the |
>                         | unreasonable man. -- George Bernard Shaw |
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 17 Nov 2005 03:35:07 -0700

louise.burness,

> If your probability of survival increases with bandwidth, you would

Maybe not at the expense of someone else's survival.

Also, I might want to reserve more, but my commanders may have
determined for me that the reservation policy is for the
greater good.

Why presume that all users are like another: that none can
have any specialized needs or requirements worthy of being
satisfied?  Why must a user be mistaken in their motive just
because they are different?

On the contrary, I think there can exist users that would
benefit from a policy that guarantees a minimum bandwidth
and provides best effort above that minimum.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 17 Nov 2005 14:05:37 +0100

Hi Louise

Are you actually indirectly saying that when RSVP is used as an
end-to-end QoS signaling protocol for a flow then DCCP must not be used
as transport layer protocol for that flow?

The previous example shows that there are cases where it is usefull to
use both DCCP and RSVP for the same flow!

Best regards,
Georgios

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, November 17, 2005 11:35 AM
Subject: Re: [Tsvwg] Re: [NSIS] interoperability problems between 
end-to-endECNandedge-to-edge ECN