Subject: Re: [Tsvwg] Next Generation TCP/IP Technology : Instant Guaranteed Service TC...

From: [email-masked]
Date: Fri, 5 Mar 2004 18:41:20 EST

In a message dated 3/5/04 10:02:21 PM GMT Daylight Time, 
[email-masked] writes:

> I am not sure exactly what this IGSTT does. There is not any technical
> detail revealed. If it's patented, it is disclosable, right?

Thank you. ideal would be controlled disclosures  

 to begin research collaborations pls sign attach NDA. complete technical 
implementations details follows 

> 
>   Without understanding what it does, it's hard to believe it can achieve
> what claims to. It sounds like it relies on competing TCP flows to
> backoff more quickly. How? Also does the real-time flow using IGSTT do
> congestion control on itself? 

yes. you guessed right !?

> 
>   How can it "Gurantee" no packet loss, if routers and switches may drop
> packets?

at the start of congestions no packets gets dropped by routers and switches , 
only later, but competing TCP flows already backoff 

> 
>   What does "Instant" mean? How fast is instant? If there is a packet drop
> in the network, does it do restransmission?
> 
> 
'Instant' as in audio-visual perception time period around 200msec max 
(and/or http tolearance wait period of eg 5 seconds). packets may be dropped due to 
eg physical transmission errors & this could
either be retransmitted if could still arrive within perception tolerance 
limit for receiver or just simply ignored for audio-visual

CONTACT
IWXChange Inc
http://iwxchange.com
EMail : [email-masked]

---

From: Sam Liang <[email-masked]>
Date: Fri, 5 Mar 2004 16:30:02 -0800

Questions inline.

> yes. you guessed right !?

  Which part I guessed right?  
  Does your audio/video flow do congestion control if there is packet drop
due to congestion?

> only later, but competing TCP flows already backoff 

  Congestion happens when routers/switches run out of buffers, or the
buffers are near full (AQM, RED). I am not sure how you distinguish "the
start of congestions" and "after" congestions. Once there is congestion,
they start to drop packets, and such packet dropping is not flow
discriminating.  Some new routers can be more smart to punish
non-responsive flows (DBL), but most routers just blindly drop packets
irregardless of the flow. So aren't your voice/video flows subject to
packet drop as well?

  Or are you doing diffServ type of thing? It doesn't seem to be imminently
deployable, since it require all the intermediate routers to upgrade.

Sam

> EMail : [email-masked]

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